Reprinted from PHARMACEUTICAL ENGINEERING®

The Official Magazine of ISPE

November/December 2010, Vol. 30 No. 6 Application of GAMP 5
www.ISPE.org ©Copyright ISPE 2010

This article
discusses how Applying GAMP 5 to Validate an ERP
the GAMP 5
quality risk System
management
strategy was
applied to an by Stephen R. Ferrell
actual case
study of a
validated
Enterprise
Resource
Planning (ERP) Introduction

R
was a legacy system. The system had not been
system. isk management concepts in the indus- previously used for GMP purposes. Therefore,
try are maturing and harmonizing as the documentation surrounding the system was
reflected in ICH Q9 Quality Risk Man- essentially non-existent in that it did little to
agement. GAMP 5® provides direction support the use of the system in a regulated
in applying these concepts in the development, environment.
implementation, and maintenance of computer- An important element when purchasing a
ized systems. Risk to the patient and product computer product or service is supplier assess-
quality continue to be the primary areas of ment, which may include supplier audit. In this
concern. This article shows how such risk-based case, however, while the system was new to the
approaches can be effectively applied to ERP GMP manufacturing plant, it had been in use
validation and compliance. supporting the business for 15 years. As a result,
Typically, Commercial Off-the-Shelf Soft- a decision was made, justified, and documented
ware (COTS) packages, including those used as with the rationale for why an audit would not
the basis for most ERP implementations, will occur. The organization acknowledged that the
be carefully tested by the suppliers before com- vendor is an established and recognized busi-
mercial release. Therefore, there is no intrinsic ness solution provider with a large user base
value in attempting to test every mouse click in the industry. The project team defined and
or every submenu in this context and it is not included relevant intended use risks in the Risk
a regulatory requirement. The focus should Assessment.
be rather on ensuring that the configuration
of the product is defined, holistic (in terms of Process
GxP1,2 and Part 113 compliance), follows actual Validation Strategy
business processes, and is verified to be fit for Creating a Computerized System Validation
intended use. Plan is a fundamental building block of any vali-
The regulated company should focus on dation project because it outlines the strategy
managing potential risk to patient safety and for the entire project. Keep in mind, however,
product quality, and ensuring compliance with that every system, implementation, organiza-
the relevant GxP regulations, including 21 CFR tion, and site is different, so rather than focus
Part 11. Additionally, they also should consider on “what goes in a validation plan,” focus rather
the impact to the overall business process. on the various document components that do
GAMP 5 defines a computerized system as: “A exist based on the legacy history of the ERP
computerized system consists of the hardware, system to determine the rationale, and the ap-
software, and network components, together proach used to outline a testing strategy. This
with the controlled functions and associated strategy can be incorporated into any validation
documentation.”4 Based on this definition, a plan or equivalent.
holistic approach was used in the implementa-
tion of the ERP system as described below. GAMP 5 Based Risk Assessment
For the purpose of this case study, the risk was
Case Study broken down into the following three compo-
Overview nents:
The ERP system discussed in this article, SAP®,

November/December 2010 PHARMACEUTICAL ENGINEERING 1

 Application of GAMP 5
1. System Risks5 One of the challenges with any Risk Assessment process
2. Criticality of User Requirements6 is the assignment of H/M/L and the dependencies between
3. GMP T-Codes (Transaction Codes)7 justifying one risk as higher than any other. GAMP 59 pro-
vided the following error occurrence by transaction: 100=L,
Each function in the system has an associated code. Using 1000=M, 10000=H. GAMP 5 suggests that a scientific ap-
a transaction code enables quicker access to any task in the proach to Risk Assessment be applied. After much debate,
system. the approach agreed upon was to rely on the knowledge
and collective experience of the workshop teams to create
System Risks a baseline for H/M/L assignation and then to consistently
A system Risk Assessment (RA) was prepared early in this apply it to the system.
project before the URS was written. It was essential that the This assessment was additionally used to provide prior-
project team agreed on the specific high level risks and func- ity targeting for remediation, and the results broke down as
tions that one would expect an ERP system to control. The follows: 105 High / 84 Medium / 57 Low priority for remedia-
project team used the SAP® whitepaper “Complying with US tion. Ultimately, the RA was revisited at the conclusion of the
FDA Title 21 CFR Part 11 for the Life Sciences Industry,”22 as project to ensure all remedial actions were traced regardless
a starting point for the team providing insight into SAP® func- of priority.
tionality. The concepts in the whitepaper were easily translated
by the non-SAP® specialist business units and then filtered Risk-Based Criticality of User Requirements10
for applicability to our business model. It is very beneficial to The seven step process below describes how the team lever-
leverage what is available from the vendor on the specifics of aged the regulations and utilized the existing system docu-
the ERP system as the requirements are created. mentation to aid in building the User Requirements. This
Risk Assessment Workshops were formed and risk was process aided in the risk analysis and testing required to
discussed in the context of the functions that would be rel- execute the project.
evant to the business units going forward. Representation
at the workshops included Manufacturing, Production Plan- Step 1 – The Regulations
ning, Quality Assurance, Quality Control, Distribution, Sales, Many regulations clearly apply in this case, including: 21
Customer Service, IT, and Validation. CFR Part 11, Part 210 Part 211, Part 820, and EU Vol. 4
Ultimately, the following four themes repeated themselves Annex 11.23
as potential remedial actions were developed: An ERP system plugs into almost every part of the busi-
ness process. The project team reviewed the functionality of
1. ensure configuration is well defined the system and assessed the functions and filtered through
2. ensure configuration is adequately tested the main GMP (Part 820). This early exercise enabled the
3. ensure configuration is managed post-go live development of very low level GMP-centric user requirements
4. ensure users are trained on said configuration that the system would have to conform to be compliant. This
activity was done internally by the validation team prior to
The company was able to apply the four themes in the context user requirement workshops. This created a first pass “must
of their own business model to develop the following: haves” that the business could build the system around to be
GMP compliant.
• Define
- create the user, configuration, functional and design Step 2 – Recycle
specification Most GMP regulated operating companies will already have
• Test an ERP or similar system in place. If a company has been
- build validation scripts regulated for a while, there may already be a validation
• Manage package from a previous system that could be recycled, and
- create ERP friendly SOPs perhaps a number of change control packages to use. In this
• Train case study, using a high level Risk Assessment system, the
- teach the business how to use the system company was able to discern which parts and pieces of our
original URS (which was system neutral) were applicable to
The Risk Assessment included key GMP risks and other busi- the current business process.
ness risks, including those related to Sarbanes-Oxley (SOX).8
All risk considerations were evaluated and where applicable, Step 3 – Business Needs/User Requirement
remedial actions were identified based on criticality. Each risk Workshops
identified was clearly designated as GMP or otherwise. As the In order to make the process as focused as possible, User
project progressed, the Risk Assessment was revisited twice; Requirements workshops were formed with the various
once after the User Requirements were defined and again functional groups. All user groups were given the skeleton
after the Business Blueprinting or Functional Specifications URS two weeks in advance of the first workshop and were
were written. encouraged to add, subtract, edit, and comment. The com-

2 PHARMACEUTICAL ENGINEERING November/December 2010

 Application of GAMP 5
mented URSs were consolidated and ultimately yielded in execute correctly. Within SAP®, Master Data plays a very
excess of 3000 user requirements, some duplicated, some important role and can cause significant system issues if not
ambiguous, some bizarre. formatted or defined correctly. Where possible, Master Data
Next, three half day workshops per week for four weeks considerations were included in this section.
were scheduled, each and every URS was reviewed, and a
unique identifier for traceability (like PP-164 or OH-23) was Step 7 – Interfaces13
captured. Each URS was given a criticality number directly Beyond a bar-coding system, the ERP instance does not have
correlating to its impact on the GMPs and Part 11. These any major peripheral interfaces; due to the nature of the
were: formation of sub teams (by ERP Module); however, there was
reference to the ERP Modules that any particular function set
• Mandatory URS Ranked as a “1” – GMP or GMP and Busi- was or could impact. This facilitated the sub team communica-
ness Critical tions as cross functional processes were developed.
• Beneficial URS Ranked as a “2” – non-GMP, but Business
Critical GAMP 5 Based System Configuration14
• “Nice to have” URS Ranked as a “3” – non-GMP Non Busi- This posed a challenge as the legacy ERP system was already
ness Critical in place. As previously described, the system had been used
for non-GMP purposes; therefore, documentation that had
At the end of the four weeks, the following user requirements been created while valuable to the ERP team was not easily
were captured: translated into the regulated context.
The configuration definition process15 was split into two
• 396 level “1” parts. For the servers, operating systems and core ERP build,
• 1157 level “2” System Configuration Specification (Core SCS) was created.
• 198 level “3” This allowed verification to occur simultaneously thereby
qualifying the hardware and core software, while the ERP
This approach achieved two key goals. First, by virtue of the analysts were translating the user requirements. For the actual
risk and criticality process, the GMP testing burden was configuration or customization of the ERP, the decision was
reduced to a little less than 400 requirements and second, made to use the legacy system as a baseline, documenting all
a requirements document was now available for the ERP changes that were necessitated by our compliance require-
analysts to build from. This document was developed by all ments utilizing additional Configuration Documents (CFD).
key stakeholders, including QA.
Part 1 – Hardware and Core Software SCS16
Step 4 – Blue Printing GAMP 5 Appendix D3 provides a check list for SCS content.
In order to translate the neutral user requirements into ERP Also, the team utilized the “IT Infrastructure Control and
centric functional requirements, a suite of Process Design Compliance Guide.”17 Depending upon the roles and responsi-
Documents (PDD) (Functional Specifications) was created. The bilities defined in your organization, the documentation can be
goal of the PDDs was to define the system in a way that could managed effectively with well defined roles and responsibilities
be understood by both the analysts and business. Each PDD assigned to each business unit within the company. For this
was traceable back to as many as 30 URSs and all business project, splitting the configuration documentation allowed the
processes were defined graphically using MS Visio. team to engage a completely separate resource pool at the
The process flows integrated into PDDs gradually formed component level and frame a schematic of the system. Specific
a picture of what the system would look like post go-live sections of the SCS have been chosen to highlight some key
and the use of the ERP integrated into our business process information that was gathered and documented.
started to take shape. Later, the flows were used as a basis
for PQ and the PDDs were tied to the new SOPs, which then ERP Infrastructure Hardware Configuration
in turn formed the baseline for process change control. The server setup is considered standard and consists of the
In addition to the process flows, the ERP Implementation following four environments:
Team translated URS into functional processes broken down
by Functions, Data, or Interfaces. 1. Development
2. Sandbox
Step 5 – Functions11 3. Quality (Test)
Each collection of URSs was translated into the appropriate 4. Production
function set in the ERP; any inputs, outputs, calculations, con-
figuration, or security considerations were captured here. Note that this vendor recommends installing the application
server and central database server on separate machines and
Step 6 – Data12 placing them in a separate subnet. It is beneficial to seek
The data section was mainly focused on those data elements affirmation and supporting information from the vendor on
necessary to be considered for the function set in scope to installation requirements.

November/December 2010 PHARMACEUTICAL ENGINEERING 3

 Application of GAMP 5
ID Item Description ID Item Description
SCS-01. Host Prod007 SCS-12. Model Cisco 3750G
SCS-02. Model IBM P570 SCS-13. Serial Number CAT0923ABC2
CAT0923 ABC 1
SCS-03. Operating System AIX 5.3.7.0, 64 bit CAT0923 ABC W
SCS-04. Other applications installed: DB2 9.3.1 CAT0923 ABC L

SCS-05. Processors (CPU) 1 – 16 POWER5/POWER6 SCS-14. Number of Ports 24

SCS-06. CPU Speed 1.0 – 4.7 GHz CPU clock rate Table B. Server configuration.

SCS-07. RAM 12 – 28 GB
Network Topology
SCS-08. Disk Space 660 – 1200 GB
Table D describes the various components that were mapped
SCS-09. Network Ports Minimum 1 Network Port and later qualified.
SCS-10. Logical Partition Yes
SCS-11. LPAR Details 4 FC Adapter Transport Management
2 Network Adapter Figure 1 illustrates how the transport process flow is man-
Table A. ERP infrastructure hardware configuration. aged from Sandbox to Development, from Development to
QA, and then ultimately into production. It is important to
Table A illustrates how each server was broken down. Table define and control the transport method and flow. This should
B illustrates how each switch was broken down. be incorporated into the change control system.

ERP Infrastructure Environmental Conditions Peripheral System Interfaces
It may seem redundant to capture and verify environmental The last key element to discuss in the Core SCS are Peripheral
conditions, especially considering the servers had already been Systems. It is important to understand the data input into
used in support of the application. However, failure to ensure the ERP, the data source, and the controls around that source.
a temperate and sustained environment for your servers can Equally, one must understand what system the ERP output
have a significant business impact - Table C. data is sent to for use. Those interfaces and the associated
systems should be carefully evaluated to determine GMP use
Physical Security and subsequently their validation status. Examples from this
All of the Physical Security attributes were defined and implementation included a barcode system, a LIMS, and a
later formally verified for the various data centers around Labeling System.
the globe.
Part 2 – Customizing the Application and
Database Security Profiles Configuration Documents (GAMP 5 Appendix
An important and easily overlooked component to any client/ D3 – 3.3.5 Software Design)
server system is database security, i.e., who has access to As described earlier, the ERP system was used for non-GMP
your back-end tables. Typically, application security will not purposes; therefore, the configuration documentation was
address those accessing your servers from outside the ap- not very reliable. The idea of examining and categorizing all
plication. For this ERP system, the Administrator Accounts, of the various customizations of the past would prove to be a
Administrators Roles, Role Mapping, Data Exchange Account, non-value added exercise, and it became very apparent that
and Unix Access were defined. Again, the “buckets” are not doing so would not be practical, due to the required customi-
as important as the content, and who can access the data. It zation to further achieve compliance.
is important to understand who can do what, define it, and
control the access to the data.

Figure 1. Transport management.

4 PHARMACEUTICAL ENGINEERING November/December 2010

 Application of GAMP 5
ID Hardware Requirement
p 570 Servers
SCS-15. Operating Temperature 5°C to 35°C (41°F to 95°F)
SCS-16. Relative Humidity 8% to 80%
SCS-17. Operating Voltage 200 to 240 VAC 50/60 Hz
Table C. ERP infrastructure environmental conditions.

Configuration Documents (CFD)

Setting static configuration within the ERP application is
typically limited to the ERP Analysts. It is not recommended
to allow all user levels to have this privilege since without
checks and balances (change control) chaos can quickly become
the order of the day.
One of the ways to capture your configuration is by a screen Table D. Network topology.
shot. In fact, by adopting the screen shot approach, it is pos-
sible to quickly show both the before and after configuration, • Server hardware placed under change control early.
especially important when revising a “living” system. • Validation resources fully engaged.
Before and after screen shots provided a brief description of • Activity complete before OQ authoring began.
the change in scope, its reason for being, and the data objects • IQ uncovered issue with backup configuration that would
and modules affected. have caused delay in system recovery time.
Since they were close to 300 CFDs, an additional “Custom
SCS” document was created to act as an anchor. CFDs were IQ Strategy Phase 2
individually numbered and titled using the Master SCS IQ Phase 2 was perhaps the most challenging part of the
number, this would help later during verification. project from a resource and testing perspective. Early on, it
was decided to focus the configuration verification only on
Non-GMP T-Codes (Transaction Codes) those changes that were necessary to achieve GMP compli-
The SOX18 and business requirements and segregation of du- ance. With the 300 CFDs in hand, the documents were verified
ties for user access had previously been defined by the Internal against the system. An onshore/offshore model was used to
Audit Group and had been administered and analyzed since reduce costs. Somewhere, the phrase “document the system”
the inception of the SOX19 rule. Therefore, no additional work got lost in translation.
in relation to those T-Codes was necessary. As the verification process began, there were a number of
situations where the configuration in the system didn’t match
GMP T-Codes (Transaction Codes) the CFDs. Each time that occurred, the issues were fed through
In addition to the CFD indexing, the “Custom SCS” also in- the deviation system to determine whether the system was
cluded a list of GMP T-Codes. T-Codes are short macros which correct, the document was correct, or both required revision
SAP® uses to execute a series of commands against user or and synchronization.
system provided input. Typical out of the box ERP systems Though under significant time pressure, the validation
provide several hundred T-Codes and additional customized team refused to let the OQ commence until CFDs were cor-
T-Codes can be created as needed. rect and there was a verified configured baseline to execute
GMP T-Codes were identified for two reasons: first, to make the OQ on. Ultimately, the pain of having to create deviations
sure they were all defined for subsequent testing, second to and recreate CFDs drove a “right first time” mentality which
create a basis for user administration post-validation. The prevailed through the end of the project.
list of T-Codes came from the following two sources: 1. SAP®’s
Whitepaper22 and 2. the segregation of all of the security OQ Strategy
centric user requirements translated into T-Codes. Regulators are focused on ensuring that a company’s com-
puterized quality systems and business intended use are
IQ Strategy Phase 1 GMP compliant. Regulators are not focused on a company’s
IQ was broken down into two discrete phases. The first phase business or financial goals, but the quality and safety of the
verified by way of test cases based on what had been defined in product for public use.
the Core SCS. This was done as a parallel activity and began The test cases were focused exclusively on the URSs ranked
while the ERP Analysts were still working on translating the as “1” or “GMP” to satisfy the regulators and the business
User Requirements into Process Design Documents. This ap- requirements ranked as “2”. As with all validation efforts, the
proach yielded the following benefits: test cases’ authors were tasked with ensuring complete cover-
age to the URS and were tasked with completing the relevant
• All servers identified by the network topology were quali- sections of the traceability matrix as they wrote tests.
fied.
November/December 2010 PHARMACEUTICAL ENGINEERING 5
 Application of GAMP 5
An independent approach to review and approval was in at least three ERP implementations and validation. Like
practiced to ensure that as soon as test cases were ready, they our veteran ERP team I expected issues. We had set up a
were pre-approved and executed. While we started with Test war room and validation triage, and waited. After being open
Case 1 and went all the way to Test Case 85, they were not only three days our field hospital was closed due to lack of
executed in numerical order, but on a first come, first served patients.
basis. Since at this point the traceability matrix was a living
document, it was easy to discern where any regression testing Traceability Matrix
was necessary and ultimately very little had to be done. Since the risk management approach was split into two parts
The design of the ERP test cases, though compliant with (Risk Assessment and the Criticality Ratings in the URS),
the SOPs, does differ slightly from the usual template. Due the Traceability Matrix was too.
to the prominence of T-Codes in the SAP® landscape, a T- The first matrix, as described earlier, was built by the
Code column was added into the test case directly after the testers as they completed the OQ, and traced URS to OQ.
instructional step. This allowed the reaction of T-Codes against The second matrix traced the high level risks driven from the
the configuration to be tested over and over again. It also Risk Workshops to the PQ and our SOPs ensuring that each
served as a training tool for the business as they continued risk identified had a completed verifiable remedial action.
to familiarize themselves with the application. This approached allowed the gap to be filled in which can
Typical to any OQ, it contained positive and negative sometimes occur between the RA and the URS and ensured
testing,20 ensured the integrity of audit trails verified and that the process had adequately addressed all of the risks
captured screen shots, and executed queries. Additionally, and requirements.
where a business process had been really well defined and was
SAP® heavy, a third party application captured a screen shot Conclusion
and transactional data as a user moves through the system. To summarize:
That raw process flow was then used as the basis for SOPs,
work instructions, and ultimately training. • Most deviations centered around poor documentation.
There were surprisingly few deviations and our OQ cov- • The system went live on time and on budget.
ered all of GMP requirements across the following modules: • Minimal to no impact to business post-go live.
Production Planning (PP), Quality Management (QM), Sales • Increased perception of value in validation.
and Distribution (SD), Customer Service (CS), Warehouse • Only five Moderate changes in first two weeks, all low
Management (WM), and Material Management (MM). impact.
Finance (FI) and Controlling (CO) also were tested though
not to the GMP level. (GDP requirements and objective evi- Since January, one full regression test cycle has been con-
dence were left to the discretion of the business). ducted further proving the integrity of the validation and the
sustainability of the change control system.
PQ Strategy A key item to note is that it started with a user commu-
In a traditional PQ, one would execute the production system nity who lacked SAP® knowledge, with an approach that was
and then after its successful completion, “go-live.” However, outside SAP® and looking in. If a similar effort was conducted
that was not possible since the non-GMP North American today, the approach would be more focused on SAP® looking
facilities were already utilizing the live system. Having previ- out, focusing more on the use of T-Codes in relation to the
ously qualified the transport tools, the technical team could business process. This may produce the same result with
port an identical likeness of the QA box21 (without data) into perhaps a little less effort.
the production environment. Verification occurred in the QA In conclusion, GAMP 5 as a tool for your ERP imple-
box, indicating the business process worked in the QA environ- mentation and validation is strongly recommended. A good
ment; therefore, they would surely work in production. validation is not a hundred binders and rooms full of paper,
Relying on the Process Design Descriptions and creating it’s a succinct risk-based effort that focuses on the FDA and
cross module test cases, the new ERP interactive business other regulators’ core concerns of product quality and patient
processes were verified. Where the OQ scripts could be more safety, and ultimately delivers a system that is as robust as
easily defined by module, the PQ was far more integrated and it is compliant.
was executed during production using the correct resources
from the business with the own login IDs and authorization References
levels. Focus on PDDs. This activity also was tied to SOPs 1. US 21 CFR PART 211 cGMP in Manufacturing, Processing,
and served as a further pre-go live training exercise. Packing, or Holding of Drugs and Finished Pharmaceuti-
By the final stage in the process, the team did not expect cals; Sec 211, 68 a and b.
many deviations and were rewarded with only human, not
2. US 21 CFR PART 820 Quality System Regulation; Sec
system errors. After 18 months of effort, a couple of million
820.70i.
dollars, the input and interaction of all facets of the busi-
ness, and three consulting companies, the system went live 5 3. US 21 CFR PART 11 Electronic Records; Electronic Sig-
January 2009. It worked. Most of the team had participated natures.

6 PHARMACEUTICAL ENGINEERING November/December 2010

 Application of GAMP 5
4. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP maceutical Engineering (ISPE), Fifth Edition, February
Computerized Systems, International Society for Phar- 2008, Appendix D3 3.3.4 – Hardware Design, www.ispe.
maceutical Engineering (ISPE), Fifth Edition, February org.
2008, Appendix G2 – Glossary and Acronyms, www.ispe.
17. ISPE GAMP® Good Practice Guide: IT Infrastructure
org.
Control and Compliance, International Society for Phar-
5. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP maceutical Engineering (ISPE), First Edition, August
Computerized Systems, International Society for Phar- 2005, www.ispe.org.
maceutical Engineering (ISPE), Fifth Edition, February
18. SOX: Sarbanes-Oxley Act of 2002 (Pub.L. 107-204, 116
2008, Section 5.2 – Applying Risk Management Based on
Stat. 745, enacted July 30, 2002).
the Business Process, www.ispe.org.
19. SOX: Sarbanes-Oxley Act of 2002 (Pub.L. 107-204, 116
6. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP
Stat. 745, enacted July 30, 2002).
Computerized Systems, International Society for Phar-
maceutical Engineering (ISPE), Fifth Edition, February 20. ISPE GAMP® Good Practice Guide: A Risk-Based Approach
2008, Section 3 – Life Cycle Approach, www.ispe.org. to Operation of GxP Computerized Systems, International
Society for Pharmaceutical Engineering (ISPE), First
7. Complying with the FDA Title 21 CFR Part 11 for the
Edition, January 2010, Appendix T1, www.ispe.org.
Life Sciences Industry – GMP Transaction Code Table.
21. ISPE GAMP® Good Practice Guide: A Risk-Based Approach
8. SOX: Sarbanes-Oxley Act of 2002 (Pub.L. 107-204, 116
to Operation of GxP Computerized Systems, International
Stat. 745, enacted July 30, 2002).
Society for Pharmaceutical Engineering (ISPE), First
9. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP Edition, January 2010, Appendix T4, www.ispe.org.
Computerized Systems, International Society for Phar-
22. “Complying with US FDA Title 21 CFR Part 11 for the
maceutical Engineering (ISPE), Fifth Edition, February
Life Sciences Industry” – http:// www.sap.com/industries/
2008, www.ispe.org.
lifesciences/pdf/BWP_FDA_title21.pdf.
10. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP
23. Volume 4, EU Guidelines to Good Manufacturing Practice,
Computerized Systems, International Society for Phar-
Medicinal Products for Human and Veterinary Use, Annex
maceutical Engineering (ISPE), Fifth Edition, February
11, Computerised Systems.
2008, Section 3 – Life Cycle Approach, www.ispe.org.

11. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP About the Author
Computerized Systems, International Society for Phar- Stephen Ferrell is a Certified Information
maceutical Engineering (ISPE), Fifth Edition, February Systems Auditor and is Certified in Risk and
2008, Appendix D2 3.2.3 – Functions, www.ispe.org. Information Systems Control. He has more
than 12 years of progressive IT experience
12. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP
with emphasis on computer system and soft-
Computerized Systems, International Society for Phar-
ware compliance, QA auditing, and quality
maceutical Engineering (ISPE), Fifth Edition, February
strategies. He is currently a member of the
2008, Appendix D2 3.2.4 – Data, www.ispe.org.
GAMP North America Steering Committee,
13. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP Chairs the GAMP IT Infrastructure SIG, is Assc. Director of
Computerized Systems, International Society for Phar- Verification & Validation, serves as a Regulatory Advisor on
maceutical Engineering (ISPE), Fifth Edition, February the Board of Sidus BioData. He can be contacted by telephone:
2008, Appendix D2 3.2.5 – Interfaces, www.ispe.org. +1-717-330-8941 or by email: stephen.ferrell@qiagen.com.
Qiagen Inc., 1201 Clopper Rd., Gaithersburg, MD 20878,
14. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP USA.
Computerized Systems, International Society for Phar-
maceutical Engineering (ISPE), Fifth Edition, February
2008, Appendix M8 – Project Change and Configuration
Management, www.ispe.org.

15. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP

Computerized Systems, International Society for Phar-
maceutical Engineering (ISPE), Fifth Edition, February
2008, Appendix D3 3.3.4 – Hardware Design, www.ispe.
org.

16. ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP

Computerized Systems, International Society for Phar-

November/December 2010 PHARMACEUTICAL ENGINEERING 7