© 2001 Cognizant Technology Solutions

Life Cycle Approach Towards Software Validation

Introduction

According to FDA guidelines, validation is confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled

Life cycle approach towards software validation ensures that validation activities occur not only at the end but also through out software development life cycle. Validation of software includes evidence that all software requirements have been implemented correctly and completely and are traceable to system requirements.

Software validation is joint responsibility of party with regulatory responsibility (for e.g. pharmaceutical company) and Software vendor. Pharmaceutical companies regularly audit software’s vendor’s quality processes, procedures and systems for compliance with GXP and FDA guidelines on software validation.

A conclusion that software is validated is highly dependent upon intended use to which software is put and requires comprehensive testing, inspections, analyses, and other verification tasks at each stage of the software development life cycle.

Regulatory requirements

Various governing bodies publish regulatory requirements. These regulations complement industry standards and quality system such as IEEE, ISO and CMM. Apart from 21 CFR Part11, software in pharmaceutical industry is also governed by regulatory requirements in GXP regulations. Some of the prominent rules outlining regulatory requirements are discussed below. GMP

Regulatory requirements as defined in Good Manufacturing Practices (21 CFR 210 and 21 CFR 211) cover areas like: Maintenance procedures Back ups and archival procedures Documentation of master formulas, specifications, test records, master production and control

records batch production records Change control procedures Data accuracy and security principles Controls on electronic record like back ups, security and retention Guidelines on record retention, reproduction accuracy, record verification, QC review etc.

Proposed amendment to cGMP regulations make validation compulsory for drug product manufacturing processes. These processes include, but not limited to, computerized systems that monitor and/ include documented rigorous testing to demonstrate the effectiveness and reproducibility of the process.

GCP

- 1 -

© 2001 Cognizant Technology Solutions

GCP regulatory requirements were developed out of need to limit malpractice. International Conference on Harmonization Good Clinical Practice defines regulatory requirements in areas including:

Trial Management covering data handling, record keeping Provision for independent data monitoring committee Maintaining audit trail, edit trail, data trail Security procedures Safeguarding blinding in Clinical Data Management

Some of the regulatory requirements defined in FDA guidance on Computerized Systems used in Clinical Trials cover areas such as:

System Maintenance Data backup, recovery and contingency Plans Security Change Control Data retrieval and reconstruction of study Software Version Control

GLP

Regulatory requirements as defined in Good Laboratory Practices cover areas like:

Identification and definition of systems Life Cycle control procedures covering requirements, design and testing Security measures Raw data verification covering raw data storage, maintenance logs, calibration records,

reconstruction of study Data Archival and Retention Quality Assurance and Training

21 CFR PART11

The scope of 21 CFR part11 regulation applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any record requirements set forth in agency regulations.” This includes the Good Clinical Practice (GCP), Good Laboratory Practice (GLP), and Good Manufacturing Practice (GMP) regulations (collectively known as the GXP regulations).

Regulatory requirements as defined in 21 CFR Part11 cover areas like:

Time-date stamped Audit Trails Document Management covering document creation, signing, modification, approval, archival

ad retrieval Security of closed and open systems covering authority checks, operations checks and

device checks Electronic records covering workflow Electronic signature covering user authentication, loss management procedures and

transaction safeguards Migration and computer system retention requirements

- 2 -

© 2001 Cognizant Technology Solutions

Software validation- Life Cycle Approach

Taking a life cycle approach towards software validation means that validation process is defined and controlled by use of plans while a process is executed through use of procedures. A validation plan should address the validation coverage based on software’s complexity and safety risk and should define the scope, approach, resources schedules, types and extent of activities and work items. Life cycle approach towards Software validation ensures compliance with regulatory requirement irrespective of software lifecycle models being followed (for e.g. spiral, waterfall etc.). Life cycle approach addresses validation by covering areas such as Requirements, Design, Construction, Testing, Change Control, Configuration Management, Training, and Defect Prevention.

Requirements

Requirements should state clearly the intended use of software. FDA specifically mentions that each requirement identified in requirements specification should be evaluated for accuracy, completeness, consistency, testability, correctness and clarity. More ever a trace ability matrix should be prepared to trace software requirements to design and to subsequent testing.

Design

- 3 -

© 2001 Cognizant Technology Solutions

Design specification can further be classified in to High-level design and low-level design. Software design should address Usability and User interface factors for user’s intuitive expectations for operation. A structured and formal design review from Quality Assurance team can allow management to confirm that all goals defined in software validation plan have been achieved. Team should comprise of people who are not part of design or development but carry sufficient functional and technical knowledge to evaluate the deliverables. Prototype and Proof of Concepts can prove to be good validation vehicles as they help in performing software risk analysis.

Construction

Definition of development procedures and coding guidelines is crucial in software validation. Evaluation of source code should be done by code reviews. Peer reviews help in validating the linkages between functional modules and different architectural layers.

Testing

Software testing at various levels help in verifying end user requirements against the software in making. While unit test plans and procedures (White box testing) help in validating the construction as per the design, System and integration testing (Black box testing) checks the conformance of software for its intended use. Formal testing processes and documentation for test plan, test results and test summaries should be maintained. Finally, a User Acceptance Testing should be performed at user site with actual hardware and software that will be part of installed system system configuration. Measures such as defects found in specifications documents, estimates of defects remaining, testing coverage, and other techniques are all used to develop an acceptable level of confidence before implementing the product.

Change Control

Change control not only attempts to maintain the integrity of validation parameters, it tests the impact of even moderate changes on functional performance. FDA guidance for software validation mentions that whenever software is changed, a validation analysis should be conducted not just for validation of individual change, but also to determine the extent and impact of that change on the entire software system. It is very important that a documented process for controlling the changes be in place and enforced.

Another often-ignored aspect of change control includes upgrades, patches or add-ons provided by software vendor. These add-ons or patches can change the parameters of a validated system and therefore their impact must be tested and validated to ensure system integrity.

Whenever changes are made to software system, sufficient regression testing should be conducted to demonstrate the correctness of implemented changes.

Configuration Management

Configuration management plan should be defined and followed to guide and control multiple parallel development activities and ensure version control and documentation.

Workspaces, where developers build, test, and debug should not be shared and code should be checked-in frequently. Code lines, the canonical sets of source files, should be given an owner. Change propagation, getting changes from one code line to another, should be propagated early and often.

- 4 -

© 2001 Cognizant Technology Solutions

Training

Persons who develop, maintain, or use systems that fall under regulatory supervision, should have the education, training, and experience to perform their assigned tasks. FDA regards this requirement as fundamental to the proper operation of a facility. Validation does not lessen the need for personnel to have the education, training, and experience to do their jobs properly.

Along with formal education (e.g., academic studies) and general industry experience, some degree of on-the-job training is expected. FDA also believes that documentation of such training is also customary. The qualifications of personnel who develop systems are relevant to the expected performance of the systems they build and their ability to explain and support these systems. It is vital that Software vendor personnel are likewise qualified to do their work.

Independence of Review

Validation activities should be conducted using independent evaluation and validation staff should not report directly to system implementation team. While one way of performing independent review is to assign internal staff members who have sufficient knowledge to evaluate the project and conduct validation. Other approach is to involve third party validation experts. Objectivity of third party vendors protects validation activities from potential conflicts with internal production schedules.

Summary

Software validation in conformance with regulatory requirements directly impacts bottom line. Cost of non-compliance, loss in client confidence and potential for legal action are big enough reasons for companies to take a structured view towards software validation.

With regulations proposed on making validation compulsory, life cycle approach can help in articulating an enterprise-wide plan when addressing software validation, including people, processes and infrastructure as well as information systems.

For further details please contact:Pankaj DubeyCognizant Technology Solutionsdpankaj@chn.cognizant.com

- 5 -