Skip links

Validation of Spreadsheets

For this edition of Call in for a Coffee we look at another topic that is becoming increasingly important for Asia’s Pharmaceutical manufactures in order to upgrade their compliance standards.

Validation of operational computer systems in manufacture is an area of particular focus for the ASEAN (Association of Southeast Asian Nations) group due to their adoption of PIC/S requirements as a common Good Manufacturing Practice standard as PIC/S requires computer systems to be validated.

As reported in a previous edition of Call in for a Coffee, the latest edition of the Good Automated Manufacturing Practice Guide (GAMP5) has been released to provide updated practical help for the validation of computerized systems. For this edition of ‘Call in for a Coffee’ we take a closer look at validating spreadsheets using GAMP5 as a basis to address the increased awareness of manufactures in the region;

Spreadsheets: Where are they used?

Many companies use spreadsheets to help process      laboratory data, to assist calculation of in process controls and finished product testing. Another use is when machine production data from a PLC is downloaded to a PC in spreadsheet form and this data is retained as part of the batch record.

Issues with spreadsheets are typically that little system documentation may be available, changes may have been made or occurred without following formal change control procedures and there may be little or no verification of the system requirements and specification leading to an unknown status of the
system and data integrity.

Another area of importance with spreadsheets is a low level of security and maintenance- including the backup and archiving of data. Usually these are not difficult problems to solve but users may not realize that they are using un-validated computer systems.

Benefits: Why should we validate?

These observations by the USA FDA are typical examples of problems we have seen in Asia.

483 citation

“Manual data input into Excel software to calculate HPLC results was not checked. Changes to standard calculation parameters were not tracked or noted by users or by supervision.”

Warning Letter

“Failure to use fully validated spreadsheets to calculate analytical results for in-process and finished product testing [21 CFR 211.165(e)].”

Warning Letter

“There is no documentation covering Excel application software, or any procedures instituted covering the protection of electronic records or and established back-up systems.”

Many regulatory inspectors are strongly aware of the vulnerability of spreadsheets and often focus attention to their use in handling GxP data.

The purpose of validation is to ensure and demonstrate fitness for use. This means that documented evidence must exist to support the usage spreadsheet.

Benefits of validation for computerized systems include improved reliability due to the implementation of Good IT Practice. This can lead to decreased operating cost and decreased cost of ownership of validated systems. In addition successfully upgrading to and achieving, higher regulatory compliance has resulted in new lucrative markets being available for regional manufactures.

Approach: What to do?

1) Determine the scope and depth of the validation

For this we use an important tool as described in GAMP, – Risk assessment.

Risk Assessment:

  • The first step is a Risk Assessment which should be used to determine the GxP aspects and the complexity of the spreadsheet application (GAMP Category) this is used to define the scope and depth of the verification (scope of testing). Spreadsheets may be GAMP category 3, 4 or 5 depending on the use of non-standard functionality / programming.

The conclusion of the risk assessment should be documented in the Validation Plan

2) Responsibilities & Planning

A Validation Plan should be produced that documents the activities determined by the assessments above. Importantly the Validation Plan should state who is responsible for completing the activities.

  Activities include:-

  • Specification and verification documentation
  • Test results
  • Change Control procedure
  • Maintenance procedure including backup
  • Operating procedures and Security Controls
  • Periodic reviews
  • Validation report

A category 3 spreadsheet application requires a simple specification and verification definition of the use of the standard functionality, a category 4 requires more specification and verification information of any defined configuration. A category 5 spreadsheet application requires design definition and rigorous verification of the custom development.

3) Requirements, Specification (& Design)

  • Sufficiently detail the requirements, for a complex application a design is required.
  • System documents are ‘live’ and should be up-to-date using typical change control procedure to make required draft, reviews and approvals.

In the case of insufficient or no system documentation being available, a current and up-to-date package should be developed. Minimally this package should state the critical requirements, (in addition a complex application requires a functional design) and the required operating procedures.

4) Verification & Reporting

  • Formal verification of the system requirements (and functionality) is required.
  • Verification is formal testing of the system to document its fitness for use against the system requirements and design. The Risk Assessment is used to highlight which functions, areas and
    requirements need to be verified. A category 5 application requires rigorous testing activity including the boundaries of inputs and positive/negative testing of the designed functionality.
  • Upon completion of the verification activities the results and final approved state of the system should be described in a Validation Report.

5) Maintaining the validated state

  • Importantly once the verification has been completed and approved via Validation Report the system is considered fit for use, however the system must be kept in the validated state.
  • This is managed by applying typical change control and configuration management procedures:
  • Changes should be assessed by considering the impact of the change (Risk Assessment), applying the changes, carrying out any verification required for the change and lastly the change must be documented.
  • Security control is a special and critical issue for spreadsheets and must be put in place and managed by Operating Procedures. A typical example is to implement read-only access for users and reviewers of data and write access only under strict control.

Conclusions & Considerations

The validation of spreadsheets handling GxP data is not only a regulatory requirement for all PIC/S countries, but when applied correctly we consider validation is good business sense.

This is due to the negative impact on organizations that may occur from failures in IT systems which are the critical infrastructure of modern business.

In order to ensure compliance for such systems it is not necessary to replace them with a large investment however the balance between retrospective validation and replacement must be addressed.