Pharma IT journall

The dedicated publication for those working with Computerised Systems,

Processes and Software in the Pharmaceutical, Biotechnology,
Medical Device, Clinical Research and Supporting Industries

Vol. 1 · No. 3 · July 2007 www.PharmaIT.co.uk

The Software
Patching Dilemma

Qualification of
Windows Servers
(Part 2)

Best Practice Guide

for Compliance
Management

Specification of
Excel Spreadsheets

Regular Features

Letter from the Editor Laboratory IT Column Compliance Corner

A Pharma IT Press publication

Pharma IT Journal

A Pragmatic Approach
to the Specification of
Excel Spreadsheets
GxP critical spreadsheets need to undergo specification to ensure that the user’s needs and the
spreadsheet’s functionality is clearly defined and documented. This paper describes a pragmatic
approach to the specification of Excel spreadsheets using a single generic document. The approach
described is easily transferred to other simple systems such as databases and standalone
instrumentation.

By David Harrison & David A Howard

Key Words: Validation, Compliance, Spreadsheets, MS Excel, 21 CFR Part 11, Pharmaceutical, GAMP, GxP, GLP, GMP, GCP, End User Computing,
Specification.

• The specification identifies each requirement with

unique numbering so that they can be later used for
traceability and qualification cross referencing.
• Where possible, information is collated into tables and
appendices to ensure a consistent and easy to
understand format.
• The process acknowledges that most spreadsheet
specifications are generated retrospectively from an
existing prototype. As such, the detailed content of the
prototype is used in the specification process to allow
the reader of the specification to better understand the
spreadsheet and its functionality.
• The version of the spreadsheet is clearly defined in the
documentation.
• A generic template document is used as the starting
Introduction point which is suitable for all spreadsheets with minimal
modification.
This continues the series of short articles describing a generic
process for validating Excel Spreadsheets. A previous article1 Specification Generation Process
gave an overview to the process, whilst a subsequent topic
The specification document is generated retrospectively once
will cover the testing and qualification.
the final version of the prototyped spreadsheet is
Although this article specifically covers Excel, the principles
complete. This is critical, as one common error is to
can be adapted to cover a wide variety of applications. This
generate the content, only to see the users change their mind
process has been successfully used on Access Databases,
on functionality, resulting in changes to the prototype. This
and other straightforward applications such as standalone ‘scope creep’ results in time consuming changes to the
instrumentation and off the shelf software packages8. The documents and an increased likelihood of errors.
focus is on minimising the document set, and providing all Specifications are usually generated by the spreadsheet
relevant information in a single generic specification with all developer and reviewed independently by a QA or validation
critical items covered. function.
This paper outlines the approach, and then provides a set Once generated and approved the specification (coupled
of questions and answers on the approach. The answers with the spreadsheet itself) is presented for qualification.
attempt to pre-empt any regulatory or QA questions that may The specification will act as a living document, and future
arise. changes to the spreadsheet (through change control) will
result in version controlled updates to the specification.
The Streamlined Specification Approach
The recommended approach is summarised below. Specification Content
• One single specification is used which incorporates the The specification document is routinely divided into two
User Requirements Specification (URS), Function distinct sections, a URS Section and a FS section. The
Specification (FS) and Design Specification (DS). approval signatures on the front page approve all content. ➧
Vol.1 · No. 3 · July 2007 www.PharmaIT.co.uk 29
 ABB managing compliance
enabling performance
ABB is an international technical consultancy providing a range of
services including licence to operate, asset management, manufacturing
improvement and capital investment to customers in the Life Sciences
business sector.

ERP Systems
ABB is a world leader in helping clients manage and implement
ERP systems to achieve early success and payback from IT
investments. Our proven SAP validation approach centres on a
holistic analysis of how the system is integrated with the business
operation, directly aligning business and project aims.
Combining experienced leadership and our ERP project
accelerators we can deliver high quality ERP validation projects
at up to 30% less cost.

End User Computing

End User Computing provides the optimal environment for
users, however the inherent flexibility can bring compliance
concerns and lead to extended validation effort. ABB are the
world leaders in spreadsheet and database compliance,
providing cost-effective and pragmatic solutions through the
use of technical controls and efficient validation processes.
Our proven turnkey solutions ensure your systems meet
both regulatory and user requirements.

Computer Systems
ABB has a proven track record in providing world class
consultancy and validation on Computer Systems (DCS, PLC,
WMS, LABS, LIMS etc) throughout the pharma industry. Whether
on new implementations or upgrades, the combination of our
widespread experience and risk based approach to validation
ensures a cost effective, pragmatic solution that fits your
business, resource and budget needs.

PAT
Quality by design (QbD) concepts based on Process Analytical
Technology (PAT) is fast becoming a corporate development
imperative for many of our pharmaceutical clients. ABB are at the
leading edge of this drive, combining our excellent technology,
regulatory consultancy and change program management skills
to offer the perfect technology partnership for our clients.

ABB Engineering Services

Daresbury Park Business Centre, Daresbury, Warrington, Cheshire. WA4 4BT.
Tel: +44 (0)1642 372000 Fax: +44 (0)1642 372111
E-mail: [email protected] www.abb.co.uk
Pharma IT Journal Specification of Excel Spreadsheets
The document is divided up into the following sections. identification of the server and whether the spreadsheet will be
operating within a 3rd party software package for added
Section 1 – Introduction security2.
Section 1 provides an introduction to the project and the goal
of the project. URS 3.4 and FS 4.4 – Electronic Record Reproduction
Describes the needs and functionality over the use and
Section 2 – System Overview availability of electronic data and records to meet 21 CFR Part
2.1 User Background 113.
2.2 System Overview
2.3 Specification Methodology URS 3.5 and FS 4.5 – Electronic Record Backup and
Section 2 provides information on the spreadsheet’s use such
Restore
as departmental background and how the spreadsheet fits into Describes the needs and functionality for accessibility of saved
the data processing/approval process. It will define the data and restored electronic records to meet 21 CFR Part 113.
used and records generated. It will provide an overview of the
spreadsheets use and function. URS 3.6 and FS 4.6 – Audit Trail
This section also provides a brief introduction to the format and Describes the needs and functionality for audit trails and
content of the document with particular note made to the use traceability to meet 21 CFR Part 113.
of Appendices.
URS 3.7 and FS 4.7 – Physical and Logical Security
Section 3 - User Requirements Describes the needs and functionality for security to meet 21
Section 3 details the user’s needs and requirements. Although CFR Part 113. This will describe the security around both the
it is generated retrospectively, it is still written as a request for application software (Excel and possibly a 3rd party software
functionality i.e. The system must do this, or the system package2) and the individual spreadsheet. It will provide detail
should do that. on workbook, worksheet and reference to cell protection.

Section 4 – Functional Specification URS 3.8 and FS 4.8 – Macro Functionality

Section 4 details the response to the User Requirements. It is Describes the needs and functionality of any macros used in the
generated retrospectively and provides a detailed description of spreadsheet. Depending upon the complexity of the macros
the functionality defined within the spreadsheet. It is written in used, this section can follow a simple or complex structure. The
the present tense i.e. The system does do this. complex structure will break out functionality into individually
In sections 3 and 4 each item is structured into numbered bullet numbered sections which details Functionality type (i.e. button,
points which allow cross reference and traceability. The majority form, etc), VBA command, Use, associated error messages
of bullets are requested in the URS section, and answered in the and cause, and audit trail entries.
FS section.
URS 3.9 and FS 4.9 – Spreadsheet Documentation
e.g.
Describes the supplied documentation such as specifications,
URS Section 3.1.2 The spreadsheet must be compatible with
SOPs for routine use and the presence of developer and user
Microsoft Excel 2002 and 2003.
training records.
FS Section 4.1.2 The spreadsheet/template can be used
within the following Microsoft Excel application software
URS 3.10 and FS 4.10 – GxP Records and Approval
versions (Excel 97, Excel 2000, Excel XP, Excel 2003).
Signature Functionality
Identifies GxP critical electronic records to meet 21 CFR Part
For many of the requirements this functional response is a
straightforward confirmation of the need; for other requirements 113 and describes the process for handwritten or electronic
the FS section of the document will expand the detail to explain approval of the data.
how the functionality works.
URS 3.11 and FS 4.11 – Data Calculation
The following descriptions detail the relevant subsections of Requirements
sections 3 and 4; the descriptions are combined in this paper,
but are separate in the specification document. Describes the detailed functionality of the calculations and
formulas within the spreadsheet. This section is usually
URS 3.1 and FS 4.1 – Application Software substantial and always unique to each spreadsheet, as such the
content is transferred out to suitable tables within Appendix A
Describes the versions of Excel (and any other relevant software).
for the URS and Appendix B for the FS. See examples below.
URS 3.2 and FS 4.2 – Spreadsheet Workbook
URS 3.12 and FS 4.12 – Input/Output Requirements
Characteristics
and Data Flow
Describes the way in which the spreadsheet is structured into Describes the detailed functionality of input and output such as
workbooks and worksheets. It will define the number of each Excel data validation, conditional formatting, and the process by
and whether they operate as XLS or XLT files. which any data is imported/exported in the spreadsheet. For
many of these functions cross reference can be made to
URS 3.3 and FS 4.3 – Location of Operation Appendices A/B or to macros detailed elsewhere in the
Describes the proposed location of operation such as document. ➧
Vol.1 · No. 3 · July 2007 www.PharmaIT.co.uk 31
Specification of Excel Spreadsheets Pharma IT Journal

URS 3.13 and FS 4.13 – Information Printout This method may seem overcomplicated for such a simple
Describes and displays the visual representation of the example, but in reality spreadsheets are never this straight
spreadsheet in use and any printed spreadsheet output. This forward, and wordy descriptions are extremely cumbersome.
section is usually covered by screen prints and printouts From our experience this provides a consistent and efficient
which are provided in Appendix C. method of listing user requirements.

URS 3.14 and FS 4.14 – Miscellaneous Appendix B – Functional Specification and

Requirements Worksheet Contents
This section describes the spreadsheet content. Wordy
Describes the needs and functionality for any items not
descriptions do not work, and that the simplest way to cover
covered in previous sections. Example may include
this is to printout the whole of the spreadsheets content.
information on any manual processes that link this
This can be done manually using a display option in Excel
spreadsheets output to another system.
(Tools, Options, View, Show formulas) (Fig. 1).
Alternatively this output can be automatically generated by
Section 5 – Glossary and Section 6 – References
commercially available reporting tools such as Exchecker4, or
Describes the acronyms and references used. Often the Power Utilities Pak5.
references will refer back to the testing of other applications Our approach is performed using a combination of these
such as any testing of the Excel environment or 3rd party products and provides us with an output direct into MS word
software packages2. as shown below. This example table has been cut down to
show example lines only.
Appendix A – User Requirements Table Details Similar tables will exist for a variety of detailed content such
Describing how a spreadsheet works is difficult to put into as File Information, Links, Names, Comments, Data
words, especially if the spreadsheet is complex and has Validation, Conditional formatting, Charts, macros etc.
multiple interlinked tables and look ups. Experience has
shown us that although wordy descriptions work fine for Appendix C – Workbook Display & Printouts
simple spreadsheets, they quickly become unmanageable This section includes visual images of how the spreadsheet
and confusing for larger spreadsheets. This problem is looks on screen and how any printed output looks. It is
compounded by the fact that two people will describe the invaluable in allowing the reader to get a clear picture of the
functionality very differently in words. how the spreadsheet works and processes data. This
Our approach to defining user needs and calculations is section is also vital as the printed output is often the
done using tables as shown below (Table. 1). Worksheets are information that is submitted for regulatory approval and
broken down into tables and each table’s need is defined by storage.
the user. Unique references for any calculations are defined at
this stage to allow the start of the traceability through FS and Appendix D – Macros Included In Workbook
qualification. Note that only verifiable ‘calculation’ cells are This section includes the source code printout of any macros
specified in this user requirements section; this would include included in the spreadsheet.
formulae, conditional formats, data validation and graphical
ranges. Data input cells and constant text cells are not Appendix E – Training Records
included. This section includes evidence of the training records of
The user requirements are also supported at this stage by developers of the spreadsheet as requested by 21 CFR Part
a fully functional prototype of the spreadsheet (printouts of 113. For simple spreadsheets this would include evidence of
which are included in Appendix C of the specification), and User Training in the use of Excel and in the requirements of
therefore this table, combined with the visual image allows 21 CFR Part 11 and computer systems validation.
the reader to get a clear picture of the user’s needs and how For spreadsheets with macros it would include evidence of
the spreadsheet works and processes data. programmer qualifications and experience in VBA.

Table A.1 Worksheet Name: Data Sheet Table Name: Header Information and Calculation
This table contains details on the electronic file and spreadsheet calculation. It provides a mean and StDev of the data input values and provides
a final results of mean value multiplied by concentration.
Calc. Cell No. Comments
Ref. Name/Description Cells
A.1.1 Date/Time Stamp 1 Must displays MODIFIED_TIMESTAMP field generated from the DaCS system. Timestamp must update
every time the spreadsheet content is changed or updated.
A.1.2 Filename Stamp 1 Must displays FILENAME field generated from the DaCS system. Filestamp must update every time the
spreadsheet content is changed or updated.
A.1.3 Assay Description 1 Data Validation Lookup - User must be able to select the assay type about to be reported upon from a
drop down menu. Choices include. Assay 1, Assay 2, Assay 3.
A.1.4 Mean Result 10 Table must provide a mean result for each row of data input values.
A.1.4 StDev Result 10 Table must provide a standard deviation for each row of data input values.
A.1.4 Final Result 1 Table must provide a calculation of the average of the (Mean Result * Concentration Factor).

Table. 1 User needs and calculations defined in tabular format

32 www.PharmaIT.co.uk Vol.1 · No. 3 · July 2007

Pharma IT Journal Specification of Excel Spreadsheets

Figure. 1 Printing the spreadsheet content

Cell Cell Cell Formula / Value Locked Hidden Merged Merged

Address Format Type Range
D2 General Constant Spreadsheet Name: True False No
E2 General Constant ABB Example True False No
B5 General Constant Assay Description True False Yes B5:H5
B6 General Data Entry False False Yes B6:H6
C9 General Constant Weight of Item 1 True False No
F9 General Constant Concentration Factor True False No
G9 General Constant Mean True False No
H9 General Constant SD True False No
C10 0.00 Data Entry False False No
F10 0.000 Data Entry False False No
G10 0.00 Formula =IF(ISERROR(AVERAGE(C10:E10)),””,AVERAGE(C10:E10)) True False No
H10 0.00 Formula =IF(ISERROR(STDEV(C10:E10)),””,STDEV(C10:E10)) True False No
B21 General Constant Final Result True False No
C21 0.00 Formula =IF(ISERROR(AVERAGE(G10:G19)*AVERAGE(F10:F19)),””,AVERAGE(G10:G19) True False No
*AVERAGE(F10:F19))
B23 General Constant Filename: True False No
C23 General Formula =IF(ISBLANK(FILENAME),””,FILENAME) True False Yes C23:H23
B24 General Constant Date: True False No
C24 dd mmm yyyy Formula =IF(ISBLANK(MODIFIED_TIMESTAMP),””,MODIFIED_TIMESTAMP) True False Yes C24:H24
hh:mm:ss
Table. 2 Example of printout

Appendix F – Risk Assessment

This section documents the functional risk assessment (FRA) of
the spreadsheet. The risk assessment will highlight risks
associated with the use of the spreadsheet; each identified risk
will be prioritised and critical risks will be mitigated. The standard
approach used is GAMP6 based and very similar to the Risk
Assessment Approaches for the Validation of Commercial
Computerised Systems7 identified by other authors.

Challenging The Streamlined Approach

The approach recommended above is a simplified process
compared to what you would normally undertake for
specifying a major computer system, and as such normally
generates a number of questions. The following questions
and answers pre-empt those questions and give the authors
view on why the approach is ideally suited for the applications
Table. 3 Workbook and display printout we are dealing with. ➧
Vol.1 · No. 3 · July 2007 www.PharmaIT.co.uk 33
Specification of Excel Spreadsheets Pharma IT Journal

1. Question. Is there any regulatory document that 4. Question. Can we generate separate specification
states you can / cannot combine the URS with the documents and still follow the approach being
FS? recommended?
No, not that we are aware of! Companies will be Of course. Returning to the traditional approach of
expected to document User Requirements, and how having separate documents for URS and FS is
the system functions. How you document it is not common, but will take additional work, and therefore
normally defined, only that it is clear, accurate and cost you more in money and resources. It will also
allows traceability. slow down the approval and review process.
Experience has showed that the document review and
2. Question. Our QA policy states that we must have approval process is often a bottle neck in the
a separate URS!
validation process.
The recommended approach is an attempt to save you
time and resources by streamlining the process. If your 5. Question. The headings recommended don’t
policies state that you must work in a certain way then match our corporate procedures on what should
unfortunately you will have to follow them. Being out of exist in a specification document.
compliance with your own procedures is a serious
breach, and one which is difficult to defend. The headings provided are the generic ones and often
companies wish to change them to match up with their
The simple answer to this dilemma is that you should
own corporate standards which is fine. These headings
modify your corporate policies and procedures to allow
are provided to ensure you cover the key subjects and
such a streamlined approach where appropriate.
Most companies allow this approach, and it is key in the items that need to be specified.
new “risk based” validation philosophies that people
take. 6. Question. A generic specification implies that the
content is the same for many of our spreadsheets.
Updating and improving your corporate policies in this
All our spreadsheets are very different.
way will benefit other projects in the future.
Every spreadsheet is different, however many of the
3. Question. Normally the User generates the URS underlying requirements from a spreadsheet are the
and the software suppler generates the FS. How same or very similar.
does this fit when we do it all ourselves? For example,
The concept of user and supplier does not fit well for • Your need to have procedures and documentation in
spreadsheets, as it is often the user who developed the place, such as spreadsheet operation, backup and
spreadsheet. A division between user needs and restore and training records does not change.
developing never occurred as the development was
undertaken as a prototyping activity. • Your need to comply with 21 CFR Part 11 by having
logical security and an audit trail does not change,
Most spreadsheets are developed using a rapid
and therefore your specification would be worded the
application development (RAD), using prototypes and
same for each spreadsheet.
trial and error until it is ready to use. This approach is
common and acceptable as long as you build your Clearly the evidence that each of these requirements
validation process around it. has been met would need to be verified individually
When you prototype in this way the common practice is at the qualification stage, but at the specification
to retrospectively generate your URS and FS. stage many of these needs and responses are
Retrospectively generating the FS is simple and makes identical.
perfect sense, whilst retrospectively generating a URS Certain sections of the specification (such as Appendix
often seems strange as you list what you have, rather A, B, and C) will be very different for each spreadsheet.
than what you need. This is the reason these sections are taken out into
Your auditor wants to see user needs and the actual Appendices; it allows the document writer to know
operation specified, how you get to this situation is immediately the areas that need close attention in the
secondary. generation process.

Cell Cell Cell Formula / Value Locked Hidden Merged Merged

Address Format Type Range
C10 0.00 Data Entry False False No
F10 0.000 Data Entry False False No
G10 0.00 Formula =IF(ISERROR(AVERAGE(C10:E10)),””,AVERAGE(C10:E10)) True False No
H10 0.00 Formula =IF(ISERROR(STDEV(C10:E10)),””,STDEV(C10:E10)) True False No
Followed by identical row content until row 999
C999 0.00 Data Entry False False No
F999 0.000 Data Entry False False No
G999 0.00 Formula =IF(ISERROR(AVERAGE(C999:E999)),””,AVERAGE(C999:E999)) True False No
H999 0.00 Formula =IF(ISERROR(STDEV(C999:E999)),””,STDEV(C999:E1999)) True False No
Table. 4 Example of procedure for repeated large spreadsheet

34 www.PharmaIT.co.uk Vol.1 · No. 3 · July 2007

Pharma IT Journal Specification of Excel Spreadsheets
7. Question. If we use macros do we have to printout validation a difficult area to interpret. In this situation you
the source code in the specification? can only do what you think is correct and defend your
There is no specific need to list the macro’s source code, approach.
but with spreadsheet macros it is usually done this way for Be careful not to confuse what an auditor asked for with
completeness due to the fact that the code listing is small, your complex systems with what they will expect with a
and the effort and confidentiality issues over printing are spreadsheet or standalone instrument, they are not
minor. comparable and neither should your validation
approach be.
8. Question. Our spreadsheet is huge, do we have to The approach presented in this paper has been through
printout all the formulas? many inspections, and to date it has not been challenged
Normally the whole content of the spreadsheet would be by a regulatory inspector. It has however been
printed out and stored in Appendix B. However, on very challenged on many occasions for not meeting local QA
large repeated spreadsheets this is often overkill. Many requirements, or for being different to the validation
spreadsheets will have the same formulas repeated in an approach taken for other more complex systems.
identical fashion for many hundreds or thousands of rows,
There is a simple (but not recommended) answer to this
often the only thing that changes is the row reference in
dilemma, and that is to perform the full validation lifecycle
the formula. In this situation we would list the content to
on each individual spreadsheet. Generating a VP, URS,
shorten the specification content (see Table. 4).
SDS, Source Code Review, FS, IQ, IQR, OQ, OQR, PQ,
This presents minimal risk, and with recent error checking PQR, VR for each spreadsheet would certainly solve your
tools in Excel4, if individual rows were inconsistent you worries over consistency and completeness. It would
would see the error at the prototyping or qualification however also financially cripple your validation effort and
stage. tie up valuable resources in areas which most people
would consider unnecessary. You could also ask the
9. Question. Our spreadsheet is huge, do we have to question as to whether an extensive ‘full lifecycle’ suite of
printout all the formulas to paper?
documents is any more likely to ensure an error-free
Normally this would be done, but sometimes electronic spreadsheet? Our belief is that it does nothing to reduce
media can be used to help save on paper. Our preferred spreadsheet errors, but is far more likely to introduce
option would be to run our reporting tools on the documentation errors.
spreadsheet and convert the generated table into PDF
The streamlined and pragmatic approach described in
format and burn it onto CD ROM. This would then stored
this article is about taking measured risks, and presenting
in a wallet in Appendix B.
the critical information in a clear yet easy to generate
format.
10. Question. Our recent inspection/auditor stated that
a separate URS was needed for System X? We can’t
Conclusion
risk combining the URS
or A streamlined approach to the specification of Excel
Our recent auditor stated that source code must be spreadsheets has been outlined in this article. This approach
printed for custom programming! condenses best industry practices into one generic
Individual auditors and inspectors will always have their specification document. This approach offers a pragmatic way
own opinion on many of the points discussed above. The to undertake a cost effective and repeatable process and it can
lack of hard and fast rules makes computer systems be adapted to simple systems other than spreadsheets. ■

David Howard David Harrison BSc MBA

BSc CChem MRSC. Principal Consultant.
Validation Consultant. ABB Engineering Services
ABB Engineering Services PO Box 99
PO Box 99 Billingham, TS23 4YS
Billingham, TS23 4YS United Kingdom
United Kingdom +44 (0)1207 544106 (Office)
+44 (0)1937 589813 (Office) +44 (0)7957 635046 (Mobile)
+44 (0)7740 051595 (Mobile) [email protected]
[email protected] www.abb.com/lifesciences
www.abb.com/lifesciences

Dave Howard is a Validation Consultant at ABB Engineering Services, Dave Harrison is a Principal Consultant at ABB Engineering Services
specialising in End User Computing applications. where he is the Product Manager for spreadsheet validation solutions.

References:
1 David A Howard & David Harrison, ABB Engineering Services. “A pragmatic 5 PUP, Power Utility Pack, J-Walk & Associates.
approach to the validation of Excel spreadsheets – Overview”. Pharma IT http://j-walk.com/ss/pup/pup6/index.htm
Journal, Vol. 1 No. 2 April 2007. 6 Good Automated Manufacturing Practice Guide, Version 4, ISPE, Tampa FL, 2001
2 DaCS™, Data Compliance System, Compassoft Inc. 7 R. D. McDowall, “Practical and Cost-Effective Risk Assessment Approaches for

http://www.spreadsheetvalidation.com/solutions/dacsproduct.htm the Validation of Commercial Computerised Systems”. Pharma IT Journal, Vol. 1

3
FDA 21 CFR 11, Electronic Records, Electronic Signatures. No. 2 April 2007.
4
Exchecker™, Compassoft Inc. http://www.compassoft.com/exchecker.htm 8
http://www.spreadsheetvalidation.com

Vol.1 · No. 3 · July 2007 www.PharmaIT.co.uk 35