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.