A PRACTICAL APPROACH TO SPREADSHEET VALIDATIONS

IN THE cGXP ENVIRONMENT

In todays fast-paced market, the ability to produce quick turn-around-time in an effective and
regulatory compliant manner is vital to a companys success. With the increased commercialization of
powerful computer spreadsheet programs such as ! "#cel, todays laboratories and manufacturing
facilities have the capability to adapt advanced technologies to traditional methods for the analysis of
laboratory data. oreover, with sound development and validation practices, spreadsheets can become
easily implemented timesavers that offer greater reliability and convenience for general purpose and
frequently used calculations.
$his article will describe the validation requirements of user-developed spreadsheets in a regulated
environment and a practical approach to addressing these requirements. ore specifically, the article
will focus on the implementation of a form-driven process for the development, verification and
regulation of end user-developed spreadsheets.
Table of Contents
Introduction
%alidation &equirements
!preadsheet 'onsiderations
( )orm-*riven (pproach
!preadsheet Initiation
!preadsheet *evelopment and )unctional $esting
%alidation *ata !ets
%alidation $esting
)ollow-+p,(pproval
!preadsheet %alidation (pprovals
!preadsheet (dministration
Introduction
$he integration of powerful spreadsheet programs into routine analytical analysis permits fast and
convenient calculations without compromising accuracy and precision. In the healthcare product
industry, spreadsheets are becoming more frequently used in regulated laboratories and production
facilities. It is apparent from recent )*( warning letters that many in industry are still unclear about
the validation requirements for spreadsheet applications. -owever, what is clear is that )*( is
increasingly concerned with the validation practices for commercial off-the-shelf .'/$!0 products such
as spreadsheet programs and has taken regulatory action based on that concern. &ecent warning letters
illustrate this point1
... Failure to validate computer software used as part of the quality system for its
intended use according to an established protocol as required by 21 CFR 820.0!i". For
e#ample$ software such as %#cel& 'ccess& and (ord used to create and maintain
databases !re)ects& complaints& and concessions" and electronic documents& is not
validated. 10 *uly 2001
... Failure to have an adequate validation procedure for computeri+ed spreadsheets
used for in,process and finished product analytical calculations. -he current validation
procedure uses only the values that result in within specification findings& aberrant
high findings& and aberrant low findings .21 CFR211. 1/0!e"1.
For e#ample& ... 2preadsheet 3alidation is deficient in that only a small range of
values are being used to challenge computeri+ed spreadsheet mathematical
calculations.
Failure to use fully validated computer spreadsheets to calculate analytical results for
in,process and finished product testing .21 CFR 211.1/0!e"1. For e#ample& the
computer spreadsheets used to calculate analytical results for ... have not been
validated.
Validation Requirements
%alidation and qualification of computerized analytical systems is not a new concept in the highly
regulated environment of the pharmaceutical, medical device and biotech industries. $he principles
behind these concepts are firmly rooted in the fundamentals that govern the c2#3 regulations. $hese
principles and practices were enacted to ensure the safety, efficacy and overall quality of a medical
product through the control of variability in all phases of its production.
4

)ollowing industrys 567 compliance initiative, a newfound awareness emerged surrounding
computerized systems and software validation. ost prominent in the new initiative is )*( and its
implementation of 64 ')& 3art 448"lectronic !ignatures and &ecords regulation. $he enhanced
awareness for 3art 44 regulations prompted a new series of guidance documents, published by industry
and regulatory agencies, covering all aspects of computerized systems validation. *espite the increase
in guidance documents, there is one area often reviewed by )*( that lacks adequate guidance9 namely
the validation of '/$! products.
In the recent )*( publication 2eneral 3rinciples of !oftware %alidation9 )inal 2uidance for Industry and
!taff, !ection :.; clearly states the requirement to validate all off-the-shelf commercial products that
lack sufficient validation documentation in order to establish that the software meets the users needs
and intended uses.
6
)or these cases, the end user, with no previous software development e#perience,
is essentially the software engineer developing and customizing a packaged application for use in the
organization. $he e#ample discussed in this article is the use of spreadsheet application packages, such
as ! "#cel, to develop spreadsheets that handle and process laboratory data.
Spreadsheet Considerations
3rior to the development of a spreadsheet solution for general-purpose applications, an organization
must review its current spreadsheet system with regard to several considerations. )irst, the
organization should decide on an established spreadsheet design standard. *esign considerations such
as spreadsheet security, use of spreadsheet templates, location of regulated spreadsheets and Windows
)ile !ystem controls should be determined before undertaking development. $he establishment of
acceptable design layouts will help ensure the uniformity and testability of an organizations
spreadsheets. !everal approaches to these topics are presented in this article.
!econdly, the organization must consider 3art 44 requirements. "ach spreadsheet must be reviewed in
the conte#t of 3art 44 to determine which sections are applicable. ( general rule is if the input data
from a spreadsheet is located originally in a laboratory notebook or worksheet, then the spreadsheet is
essentially an electronic calculator used only to process calculations. If the spreadsheet is not saved
and all calculations are validated and maintained under strict change control, then electronic records
regulation is not required. (ccording to 64 ')& 3art 44 regulations, spreadsheets that contain raw data
or are used as part of a quality system must fall under 3art 44 regulations. $herefore, if the data in the
spreadsheets contain original raw data or meta data that is essential to the analysis, then the
spreadsheets must be saved and maintained according to 3art 44 regulations. If the spreadsheet will be
used for other purposes besides processing analytical calculations .e.g., as part of the quality system0
then some risk analysis should be performed to determine the e#tent of testing needed. &isk analysis
will help analyze the effect of software failures and define the level of testing required to ensure
software integrity.
Investing some time to develop a user requirements document also will aid in spreadsheet design and
help focus the development process on required ob<ectives. $he user requirements document details
the overall purpose of the spreadsheet and specific requirements and calculations the spreadsheet will
perform, and it serves as a design and testing aid to ensure all requirements are met. /ne important
point
;
is that developing a spreadsheet is essentially software engineering and therefore must follow
sound software development practices. $o enable a spreadsheet to be tested, it must first be properly
developed with testing and validation considerations as an integral part of the development process.
$he considerations for spreadsheet validation must be made from the onset to ensure the spreadsheet
is designed for testability.
;

(s in comple# software programming, the documentation and management of a programs source code
is the foundation of a sound software development and testing infrastructure.
;
In this case, the
spreadsheets source codes are not lines of code as in traditional compiled software programs, rather
they are the formulas and functions that define the algorithm in which input data is handled and
processed. In addition, the documentation of the spreadsheet formulas and functions are e#tremely
important for spreadsheet testing, maintenance and future enhancement.
A Form-Driven Approach
In order to maintain a consistent approach to the spreadsheet validation process, a general
!preadsheet %alidation )orm .!%)0 can be created that guides users through a systematic approach
toward in-house spreadsheet validation. $he remainder of this article will detail spreadsheet
development, validation and regulation using this approach. $he goal of this process is to effectively
comply with regulatory requirements for spreadsheet implementation in both a timely and cost-
effective manner. $he ma<or phases required in this paper-based system are1
40 !preadsheet Initiation9
60 !preadsheet *evelopment and )unctional $esting9
;0 %alidation *ata !ets9
=0 %alidation $esting9
>0 )ollow-up and (pprovals9 and
:0 !preadsheet (dministration.
$he !%) is able to accommodate most spreadsheet validations and guides the user through the entire
process of spreadsheet initiation, development and functional testing, verification with manual
calculations, spreadsheet implementation, and final administration and change control procedures. $he
fact that this is a form-driven process helps simplify the full validation procedure and acts as a
checklist to ensure all components of the validation have been performed. $he intermittent approvals
and specified routing paths between the users department to Information !ystems and ultimately to
?uality (ssurance ensure the timely review and approval by all affected departments throughout all
stages of the spreadsheet validation process.
Spreadsheet Initiation
$he spreadsheet validation process begins at the inception of the idea to create a spreadsheet for
frequently used or tedious calculations. $he user initiates an !%) and obtains the required approvals to
begin the process. $he required approvals for validation pro<ects should be defined in a !tandard
/perating 3rocedure .!/30 governing software validations. $he !preadsheet %alidation )orm invokes
the creation of an !/3 and the well-accepted user requirements document to detail the requirements
of the spreadsheet. (s stated above, the user requirements document is important to provide a
framework for the design of the spreadsheet to ensure all requirements are met. $he !/3 will detail
the procedures for routine spreadsheet use and serve as the validation test procedure later on.
%alidation testing will be performed against the !/3 to verify that the procedures are suitable for the
intended use.
!preadsheet Initiation1
3rovide an overview of spreadsheet and required purpose9
@egin development of user requirements and !/39 and
/btain approval to proceed with spreadsheet development and validation.
Spreadsheet Development and Functional Testing
(fter spreadsheet development approval is granted, the user develops the spreadsheet based on the
approved user requirements document and the guidelines provided in the !preadsheet %alidation )orm.
!preadsheet development and functional testing during development is a coordinated effort that
requires input from the user, reviewer and Information !ystems *epartment .I!*0.
In this phase, the user will develop the spreadsheet, the reviewer will ensure all formulas and
functions are correct and properly documented, and I!* will apply the spreadsheet security and review
any additional functionality such as macros that may not be familiar to the reviewer or user. )or each
process step, the person e#ecuting the step must initial and date to signify completion.
$he user begins with the design of the spreadsheet, documenting all formulas and functions in the
spreadsheet onto the equation table provided in the !preadsheet %alidation )orm. $he formulas and
functions should include a description of the formula with all variables and cell ranges defined. )or any
additional functionality, the user should include the cell range, description of function and intended
behavior. $he validation form also should have some criteria on spreadsheet design to help unify the
final layout of all spreadsheets employed at the company. $he individual layout must be designated for
your organization, but should include some common feature such as shading all input cells in yellow,
adding a print date and spreadsheet version number in the body and footer of the spreadsheet,
removing all worksheets not in use, and renaming the default worksheet name .not !heet4, !heet6,
etc.0. ( section also is provided for the user to describe any known limitations of the spreadsheet.
+ser 3rocedure1
!preadsheet development according to user requirement specifications9
*ocumentation of spreadsheet formulas and additional functionality9
Individual spreadsheet formula and calculation review9
+ser testing of additional spreadsheet functions9
)inal spreadsheet layout verification .input cells shaded in yellow, print date and version
number, etc.09
!preadsheet copies printed with final layout and formulas displayed9
(ny known spreadsheet limitations documented9 and
!ign and date completion, and submit both electronic and printed copies to reviewer for
review.
+pon completion of the spreadsheet design, two hard copies of the spreadsheet are printed out, one
displaying the final layout of the spreadsheet and the other displaying the formulas showing both
column and row headings. $he reviewer reviews the electronic spreadsheet against the hard copies and
the formulas within the formula table. $he reviewer verifies complete documentation and formula
locations and confirms that the proper calculations are used along with correct synta# and order of
operation. If any discrepancy is found, it is recorded in the discrepancy log in the validation form and
the form and all documentation are returned to the user to correct. (n approval is required by the
reviewer for the successful completion of each step in the verification process.
&eviewer 3rocedure1
&eview printed validation material .spreadsheet, formula tables, validation form0 against
electronic spreadsheet1
i. review formula locations, cell numbers and ranges9
ii. review formula documentation in equation table9 and
iii. review final layout .version number, print date, yellow shade0.
&eview of formula synta# and order of operation, verify against calculator if necessary9
If the spreadsheet contains additional functionality1
i. verify the documentation in functionality table in terms of cell ranges and locations9
and
ii. verify synta# of additional functionality.
!ign and date completion, and submit both electronic and printed copies to I!* for review.
)ollowing reviewer approval, the !preadsheet %alidation )orm is routed to I!* to review any additional
functionality present .macros, conditional formatting, data validation, logical statements, etc.0. I!*
also applies the necessary security for the spreadsheet, which is ensured by password protecting all the
cells, e#cept for the data entry cells, as well as password protecting the entire spreadsheet and
workbook. $he completed spreadsheet also is resaved as a spreadsheet template and incorporated into
a protected share on the server to ensure no one can inadvertently modify the master template. $he
protected server share or some other secure location is the final destination for all regulated
spreadsheets to ensure a central storage location that can be accessed by authorized individuals only.
Aormal use of the regulated spreadsheets requires the user to change the BWorkgroup $emplatesC file
location in the ! Word,/ptions menu to a mapped network share. $he mapping of the network share
also can be regulated from the login script for specific users. (pplying this setting will allow a user to
access spreadsheets from a regulated location by selecting )ile then Aew and selecting the specific
folder or spreadsheet .in ! "#cel0. )rom I!*, the spreadsheet is forwarded to ?uality (ssurance for
approval to begin testing following the procedures outlined in the !/3. ?( will assess the quality of the
spreadsheet and !preadsheet %alidation )orm thus far and then make suggestions for improvement or
request changes to satisfy regulatory compliance, as required. (t this point, change control must be
implemented.
I!* 3rocedure1
I!* second-person review of additional functionality synta# and function9
I!* applied spreadsheet security1
i. lock all spreadsheet cells e#cept for data entry cells shaded in yellow9
ii. password protect each spreadsheet within the workbook9
iii. password protect the structure of the workbook9
iv. change spreadsheet to master template to ensure modifications are not made to
original template .D.#ls to D.#lt09 and
v. relocate master template to regulated spreadsheet drive on protected server.
I!* completes spreadsheet properties information .file name, created by, date,time created,
file size, name and version of each spreadsheet09 and
I!* routes final spreadsheet version to ?( for approval.
Validation Data Sets
While the validation material is awaiting ?( approval, the user should begin to develop several data
sets consisting of normal and erroneous,stress testing data. $he data sets should be well-documented
and reviewed for clarity and correctness prior to use. )inal verification of the spreadsheet calculations
will be based on these manual results.
%alidation *ata !ets1
*evelop normal and erroneous data sets9
*erive e#pected results for all data sets9
)or normal data sets, the e#pected results are derived based on the formulas provided in the
equation table and 4EEF proof of all calculations9
)or erroneous data sets, the results,behavior of each data set entered into the spreadsheet
is documented. !tress or limit test the spreadsheet to determine if there is a possible range of
values that may force the spreadsheet to crash .input characters, spaces, leaving blanks in
middle of cells, outrageous high,low values, scientific notation, etc.0 "rroneous data testing is
important for testing obvious errors that may be made during data entry.
!ubmit the validation data with the manual calculations for review9
+pon successful review, attach the e#pected results for each data set to the spreadsheet
validation form9
!ubmit all validation documents to I!* then ?( for approval prior to the start of validation
testing.
Validation Testing
+pon final approval of the validation data sets, a standard test procedure to verify the security of the
spreadsheet is e#ecuted during validation testing. $he security test includes testing the logical access
to the workstation, access to the regulated templates drive and the security of formula cells in the
spreadsheets. %erification of the spreadsheet calculations is e#ecuted using the approved normal and
erroneous data sets following the !/3 procedures. $he user is instructed to document the results of
validation testing in the validation form, along with any noted deviations in the discrepancy log.
%alidation $esting1
!ecurity $esting of1
i. workstation logon9
ii. regulated templates drive9
iii. data entry cells shaded in yellow9 and
iv. formula cells.
!preadsheet verification8test according to !/3 procedures1
i. normal data verification9
ii. erroneous data and stress test9
a. high,low data range stress testing9
b. invalid input9 and
c. out-of-sequence step.
Follo-!p"Approval
$he follow-up section in the !preadsheet %alidation )orm is provided to ensure that several validation
aspects are completed. )irst, verify that all necessary changes to the user requirements document
have been completed and the final version is approved. !econd, verify that the discrepancy log is
reviewed and all encountered discrepancies are properly documented and addressed. )inally, verify
that all relevant !/3s are updated as necessary, completed, and approved prior to final validation
approvals.
)ollow-+p1
%erify user requirements are updated, completed and approved9
%erify errors encountered during the entire process are documented in the discrepancy log
and have been addressed9 and
%erify all relevant !/3s are reviewed and modified if necessary.
Spreadsheet Validation Approvals
+pon completion and approval of validation testing, and necessary updates to original user
requirements, the spreadsheet may be released, using the !preadsheet %alidation )orm as the
validation report document. $he last page of the form serves as the final release of the spreadsheet
with final approvals from the user representative, department manager, I!* and ?(.
(ppendi#1
$able 41 "quation $able
$able 61 (dditional )unctionality
$able ;1 *iscrepancy Gog
$able =1 !/3 %erification
Spreadsheet Administration
$he final task to ensure regulatory compliance of spreadsheet solutions is developing a viable system
for spreadsheet administration. @esides implementing security and change control procedures, the
spreadsheet must be incorporated into calibration,preventative verification procedures and a periodic
check of the spreadsheet must be performed such that continued operation can be assured. /nce
under change control, any changes to the spreadsheet must be carried out using the change control
system and all spreadsheet versions must be maintained and archived. (s with any validated process or
product, any changes must have a review to determine what, if any, revalidations must be completed
prior to implementing the change. $his review must be documented.
/ne common problem faced by spreadsheet administrators is preventing users from saving delinquent
copies of spreadsheets locally. $his problem can be addressed by administrative controls or enforced by
%isual @asic programming. Including the current spreadsheet version number in the !/3 governing its
use is the easiest way to ensure the most up-to-date version is used. oreover, %isual @asic scripts can
be integrated into the spreadsheet to disable all menu bars, toolbars and quick keys to prevent the
data and the spreadsheet from being saved. $his method of preventing the data from being saved is
only permissible if the input data from the spreadsheet is originally located in a laboratory notebook or
worksheets9 then the controlled and validated spreadsheet is essentially an electronic calculator used
only to process calculations. If the data in the spreadsheets are original raw data, then the spreadsheet
must be saved and maintained according to 3art 44 regulations. $he problem is that commercial
spreadsheet packages were never designed to comply with these regulations and therefore using them
with full 3art 44 compliance requires e#traneous programming and,or possible third-party solutions.
Incorporating the spreadsheet into a document control system that has version control, security
permissions and an audit trail can help satisfy 3art 44 regulations. $he other option is to investigate
third-party solutions such as the Wimmer !ystems *ata 'ompliance system to help ! "#cel
spreadsheets comply with these requirements.