Understanding and Interpreting the New GAMP 5

Software Categories
Jun 01, 2009
By Spectroscopy Editors
Spectroscopy
Volume 24, Issue 6

The GAMP (Good Automated Manufacturing Practice) guide version 5 was released in March 2008 and
one of the changes was that the classification of software was revised again. This column will look at
what the changes mean for the laboratory and whether all of these should be implemented.

Version 5 of the Good Automated Manufacturing Practice (GAMP) guide (1) was released last year. This
publication has been available since 1994, when version 1 was informally published in the UK, and since its
inception it has always contained a classification of software. This is one of the best parts of the guide as it has
an in-built risk assessment, as we shall see in this column. We will explore version 5 of the software classification
and see what changes we need to make to ensure that it can be implemented practically and effectively in any
laboratory.

However, before we continue much further I should also declare a vested interest: I have a love–hate relationship
with the GAMP guide. I love the classification of software outlined in Appendix M4 and hate the life cycle V
model. My rationale for this position is that versions 1–4 of the guide presented a single life cycle V model that
was really only applicable to process equipment and manufacturing systems. It had very little to do with
computerized systems, especially laboratory ones. Therefore, every validation was shoehorned into an
inappropriate model because there was little thought and intelligence applied and the model followed blindly. For
example, when a commercially available laboratory system was validated, functional and design specifications
were written for virtually no gain but at a great cost in time and resources. The problem lay in the origins of the
GAMP guide. The first version was written by a group of volunteers in the UK in the early 1990s as a mechanism
to control suppliers of process equipment to the pharmaceutical industry, and this legacy survived through to
version 4. However, the model does not make it into version 5 of the Guide, which is a shame; as mentioned
above, the model is very good for process equipment.

However in GAMP version 5, I'm very pleased to say that the "one size fits all" approach has been replaced by a
breath of fresh air with different life cycles depending on the classification of the software being implemented.
The key message is that now a single size life cycle model does not fit all systems. Note that GAMP is a guide
and you can deviate from it — all that is required is the application of thought and intelligence coupled with
effective risk management that is well documented. OK, perhaps this is a step too far . . . .
Software Classification Categories

Table I: Comparison of software categories in GAMP 4 and GAMP 5

As I mentioned earlier, the software categories in GAMP 5 have been revised (1). To appreciate the scope of
these changes fully we need to look at the classification of software from GAMP 4 (2) and compare this with
GAMP 5, as shown in Table I.

In the beginning, or at least in GAMP 4, there were five categories of software:

 Category 1: Operating systems

 Category 2: Firmware
 Category 3: Standard software
 Category 4: Configured software
 Category 5: Custom software

The constituents of each category are outlined in Table I; however, there was always a debate about some
commercial software packages — were they category 3 or 4? Many spectroscopists would argue that an
application should be classified as category 3 and not 4, as it should be less work to validate and evade the real
classification. To help resolve this debate, in GAMP 5 the software categories have been revised and refined —
most for the better and one for the worse. This is a natural evolution of this approach to software classification.
So we now have the following four categories:

 Category 1: Infrastructure Software

 Category 3: Nonconfigured products
 Category 4: Configured products
 Category 5: Custom applications

Refer to Table I as we discuss the changes in the software classification in more detail in the next section.

Why Classify Software?

Before we go into a detailed discussion of the software categories, perhaps we should ask the question "Why
bother to classify software?". What benefit does this software classification provide?
If you look at Table I there is a built-in risk assessment. The least risky and most widely available software is in
category 1 (operating systems, databases, office software, and other widely available software). This is widely
available software that can be used by anyone and in any industry. As we progress through down the categories
as shown in Table I, generally the software becomes more specialized in its function (from a general office
application to software that can control a spectrometer to acquire and process data then report the results). As
we go down the list there is the increasing ability of the users to change the operation of software and process
the results until we reach category 5. In category 5 is a unique solution that is conceived, specified, written,
tested, and maintained by the users or the organization; here is the greatest risk. Let's now take a detailed look at
each of the software categories and see what has changed and if there are any problems we need to discuss.

Software Classification Changes and Their Laboratory Impact

Presented and discussed here are the various changes to the software classifications in the new GAMP guide.

Category 1: Greatly Expanded Scope — Infrastructure Software

Category 1 has undergone a radical change and expansion from simply operating systems, that had been
constant in GAMP versions 1 to 4, to infrastructure software. This category is broken down into two
subcategories:

 Established or commercially available layered software and

 Infrastructure software tools.

The intention is that the infrastructure software in this category provides the computing environment for running
both regulated and nonregulated applications within an organization. All software in this category needs to be
controlled and qualified in an organization so that dual standards are not applied by the IT department, which can
question the status of validated applications if not done.

Software in the subcategory of Established or Commercially Available Layered Software still includes operating
systems from GAMP 4, but this has also been expanded to encompass a greater scope:

 databases
 programming languages
 middleware
 office software
 ladder logic interpreters (for manufacturing systems),
 statistical programming tools and spreadsheet packages.

The key issue is that many of these software tools are the base products for the applications used in the
laboratory or they are the foundation layer for the laboratory applications to operate under. For example, if your
spectrometer has application software that has a database to manage the methods, data, and results you
generate, the latter is configured by the spectrometer supplier from the out-of-the-box database to operate with
their application software. Languages are used as a means to write the applications, each of which will be
validated for their intended use.

Note that category 1 also includes office software such as word processing, spreadsheet, database, and
presentation applications. Now before you rush off thinking that Excel templates and macros do not need to be
validated, think again, as the guide notes that "applications developed using these packages" are excluded from
category 1 and these can be category 3, 4, or 5, respectively (1), depending on their complexity.

Note also the phrasing of the subcategory "established or commercially available". This means that both open
source and software commercial can be used, which ratifies the status quo (open source operating systems
[Linux or OpenVMS], databases [MySQL], and source code management [SubVersion]). In many IT departments
and research groups open source software is used and often this use can be extensive. Some people may argue
that open source software is hacked code, but when the code can be reviewed by many programmers it may be
argued that the quality of the finished application could be better than some commercially available software.
Regardless of the debate, the word established allows the use of open source applications within category 1.

The second subcategory is infrastructure software tools that comprise a wide variety of software, such as

 network monitoring software

  anti-virus
 backup
 help desk
 IT configuration management tools and other network software.

While sounding like a shopping list, it provides the IT group with tools to establish, protect, monitor, and manage
their computing environment and networks and where you store your laboratory data and electronic records.
However, care needs to be taken with applications in this subcategory as the use of the application could
drastically change the category to which it is allocated. Take for example help desk or configuration management
applications. If no regulatory data are held exclusively here then they are category 1, but if they are your only
tools for problem management or change control processes for regulated applications, then this changes the
category and the validation group comes galloping round the bend.

From the laboratory, audit, and inspectional perspectives, what is required is control of the applications that
comprise group 1. Some of the typical controls will be

 identification of the software (name, version, and supplier),

 where is it installed including path to the server–virtual server,
 configuration to operate in your environment,
 demonstration that the software has been installed correctly, and
 a simple demonstration that the software works.

All should be done regardless of where the software originates: open source or commercial software.
Furthermore, change control and configuration management are essential elements of control both with category
1 and the other software categories. So we qualify these items of software, not validate them. In contrast, we
validate software in categories 3, 4, and 5. Note that I have omitted category 2 software; we will now discuss this
in more detail.

Category 2: Ignore Discontinuation of Firmware Classification — but with Care

As you can see in Table I, GAMP 4 had five categories of software, which is reduced to four in the latest version.
The category that has gone missing in action is category 2 (firmware).

The argument for this category's discontinuation from the GAMP Forum is that firmware, which can vary from
simple to custom software, can be accommodated in the other categories depending on its nature. To understand
why this category was eliminated from GAMP 5 we need to consider what we mean by the term firmware. In its
original form, firmware was a set of operating instructions for an instrument embedded in a read-only memory
(ROM) chip or used to start more complicated programs on an instrument or device. An alternative term favored
by IBM is microcode. This is software but instead of being delivered on a disk or USB stick, it comes preinstalled
on a chip having been built into the instrument during the manufacturing process.

FOR: Firmware is still software, and different chip versions will be produced over time due to bugs that will be
found and fixed by a manufacturer. When this occurs, a new version of the firmware ROM is produced. During a
maintenance visit by a service engineer (aka the Angel of Death), the firmware ROM may be replaced with a new
one. Therefore, change control must include firmware as the upgraded chip may contain new functions not
present in the existing chip as well as the bug fixes for the original software. One instance where a firmware
change may need to be upgraded is when you install a new version of instrument–data system application
software. It is possible that the drivers for your spectrometer may have changed and to ensure that the new
software works correctly, the firmware needs to be upgraded at the same time. You need to know that firmware
will be upgraded in advance so you can complete the change request before the work starts.

Over time, firmware chips have become bigger to allow more instructions to be input and the ROM can be
replaced with flash ROM, which can be erased by UV light and rewritten through a firmware updater. Other forms
of firmware can be upgraded via a download; the best example of this is the BIOS firmware chip in your PC,
which typically can be updated online to fix errors, improve functionality, and keep it current.

The biggest issue with firmware now is the ability to define programs or parametrization to produce user-defined
routines that can be kept in memory and recalled at will. A typical example is a dispenser–dilutor, in which a user
can prepare different routines for different analytical methods. So instead of a simple set of instructions there is
now the ability of the users to change the way the instrument works. However, flexibility comes at a potential
price of the impact on the results and errors if the user-defined program is incorrect. The parallel in the
conventional software world is Excel and the ability to produce incorrect templates or macros if proper controls
are not in place.

Therefore, the rationale for the discontinuation in GAMP 5 is that the software sitting on the firmware can be
classified in the remaining software categories. In doing so it should eliminate the impact of user-defined
programs that are possible with the more complex type of firmware systems.

AGAINST: Now let's look at the argument for retaining category 2 software and ignoring the GAMP 5 advice.
Looking around the laboratory you'll see many common laboratory instruments (such as balances, pH meters,
and dispenser dilutors) that still use a firmware chip to operate the instrument. Furthermore, the firmware cannot
be changed by the user and the only way for a chip update is via the service engineer. Under these
circumstances I believe that there is no need for excessive validation, and these instruments can still be qualified.

However, we now run into a slight problem. The issue is that the GAMP 5 approach is now in direct conflict with
USP <1058> for analytical instrument qualification (AIQ) (3), which we discussed in detail in the last "Focus on
Quality" column (4).

GAMP 5 says validate and USP <1058> says qualify. Oh dear, what shall we do?

This is a common problem when different professional groups develop guidance; the individual participants sit in
a silo and fail to consider anything outside their own boundaries. Hence, when each new guidance is unveiled
with a fanfare and the chink of a cash register, it is not until later that we find that due to professional myopia
there are conflicts and problems. Ironically, GAMP 4 was congruent with USP <1058> and these instruments
would be classified as category 2 software qualified to demonstrate their intended purpose, a simpler and quicker
process than validation. Under this approach the instrument's software is implicitly validated as part of the
qualification to demonstrate intended use — job done. Why do more?

POTENTIAL SOLUTION: So how do we resolve this situation? Which takes precedence — a USP general
chapter or the GAMP guide? I don't think we need to phone a friend or go 50:50 to answer this question do we?
So in the laboratory you'll want to ignore GAMP 5 and retain category 2 software for laboratory instruments and
be consistent with USP <1058>. This approach will also make your life easier in these instances.

WARNING! Implement this approach with some caution and the application of intelligence. The reason for the
warning is that most of the laboratory instruments in this section are indeed category 2 software, but some
instruments can have additional functionality that needs further control (for example, theycan have programmable
firmware for user-defined procedures that automate tasks over and above the basic functionality of the
instrument). The ability of the users to change the function of the instrument has many advantages but also
comes with a significant downside: errors and incorrect procedures. Therefore each laboratory needs to take this
into consideration when deciding the software category and hence how much qualification or validation work is
undertaken.

Therefore you'll need to adopt a two-stage process if you develop user-defined procedures.

 First, qualify the basic operation of the dispenser–dilutor as category 2 software and undertake any
calibration as necessary to ensure that the instrument is fit for its basic intended use.
 Second, any user-defined procedures must be documented and validated (specified and tested) as
separate activities. This user-defined software is category 5 but can be validated on a simpler life cycle
model, as the development platform (that is, the instrument) has already been qualified.

As you move away from simple firmware that is implicitly tested as you qualify the instrument, you will need to
take this two-stage process approach, although control of user-defined procedures can be controlled by an SOP
rather than writing a validation plan every time you develop one of these user-defined procedures. You will also
need to control the versions of each of these procedures and introduce change control to ensure that changes to
each one are managed effectively.

The other issue that you may encounter with some instruments in this category is the incorporation of
calculations in the operation of an instrument. A balance is the classic example here if it is being used for content
uniformity testing. Any calculations used as part of YOUR use of the instrument should be checked as part of the
qualification to ensure compliance with the requirement of 21 CFR 211.68(b) (. . . Input to and output from the
computer or related system of formulas or other records or data shall be checked for accuracy. The degree and
frequency of input–output verification shall be based on the complexity and reliability of the computer or related
system . . .) (6). However, the calculation checks and testing should be integrated into the overall instrument
qualification and not become a separate calculation validation in a multilayered validation approach.
Software Silos or Software Continuum?

The next three software categories we will discuss are intended as a continuum rather than discrete silos, so
some interpretation may be necessary as to which category a system falls into. This will need to be documented
in your system risk assessments or validation plans, so "think things through" is the take-home message.

Category 3 Software: What's in a Name?

Category 3 in GAMP 5 has been renamed from Standard Software to Nonconfigured Product to sharpen the
difference between this and category 4 software. Now this means that software that is used as installed falls into
category 3 and may (note the careful use of the word may) also include software that is configurable (category 4)
but is used either unconfigured or with the standard defaults provided by the software supplier.

Despite the name, category 3 software is also configured, but for the environment (run-time configuration). It is
this fact that distinguishes category 3 from category 4 software. What is run-time configuration?

 First, is that upon installation of a category 3 application, the software is capable of operating and
automating the business process without any modification — in fact, as noted in Table I in the GAMP 5
column, it cannot be changed in this respect. Some other terminology used to describe this type of
application is canned software or commercial-off-the-shelf software (COTS), or even off-the-shelf
software (OTS), but these are badly abused terms that can be misused to mislead or lie to users and
therefore will not be used in this column.
 Second, run time configuration is only the definition of items in the software to enable the system to
operate within the installed environment. Some typical run time configuration parameters are the
definition of users and user types for authorized individuals, entry of the department or company name
into report headers, selection of units to present or report data, default data storage location (either a
local or network directory), and the default printer. Reiterating the statement above, the key
characteristic of software in this category is that run time configuration does not change the automation
of the business process or the collection and analysis of the data and records generated by the
software. This is in contrast with category 4 software, in which the actual operation of the software to
support the business process is changed to match the laboratory business process.

As well as a simpler life cycle, which we will discuss in a later column, the software vendor or supplier's work in
software development can be used to save validation effort within the laboratory, as functional and design
specifications are not expected from the user. Note that this life cycle does not absolve the user from defining his
requirements and also demonstrating intended, use but the testing is only a single phase. This change helps
practitioners in the field to interpret software better: you could have the same software in category 3 or 4,
depending whether the default settings are used or if the application is configured respectively. To illustrate this
point, I have been involved in validating the same software application that was category 3 software when
operating a time-of-flight mass spectrometry (TOF-MS) system (here the application was used as installed) but
category 4 when used for bioanalysis with quantitative analysis using a triple-quadrupole MS instrument (here
electronic signatures were configured for use in the application).

Category 4: Configured Products Refined

The name of this category has changed to help refine and redefine the software categories; the guide has moved
from defining software as "package" in GAMP version 4 to "product" in GAMP version 5. I believe this is to
emphasise the commercial nature of category 3 and 4 software, which constitutes the bulk of the software used
in laboratories today.

The major difference between category 3 and 4 software, as mentioned earlier, is the ability to modify the
function of the software to match a business process. The user has the means and knowledge to change the
functionality of the device in a way that changes the results outputted by the device. As a direct consequence,
this triggers increased validation effort. There are many ways to achieve this but the essence is to take standard
software modules that provide the basic functionality to automate a process and change it by configuration tools.
These tools are provided by the vendor of the product, hence configuration rather than using an external
language to write custom code that is attached to the product. However, these tools can vary in their nature from
simple configuration buttons that turn a feature on or off to graphical drag-and-drop to a modular "configuration"
language that typically writes large blocks of software; hence, custom code, which raises the debate of
configuration versus customization.

Understanding the difference between configuration and customization is the key to managing software and
validation risk. However, many in the laboratory are seduced by suppliers marketing literature that talks of
configuration when in reality it is customization, as we'll discuss now. The main point I would like to make is
caveat emptor — buyer beware . . . . The user is responsible under the regulations, and if you are seduced by the
marketing literature, it's your problem.

Category 4 and 5 Software: Configure versus Customize — Where Is the Line?

Configuration and customization of software are terms that are poorly defined in the validation world and
frequently used interchangeably, especially in a vendor's marketing literature. It is important to understand the
difference between these two terms as they mean entirely different things and consequently can have a dramatic
impact on the amount of validation work that you could undertake.

The problem is that even the FDA and GAMP have not been able to define these terms, as configuration and
custom are missing from the glossaries from the FDA (5) and GAMP 5 (1). However, an issue arises when a
"configuration" or scripting language is provided by a software vendor to enable the modification of a program's
function to fit the business process. Regardless of terminology, this language writes custom code within the
application. The problem is a vendor's marketing department has typically cottoned on to the idea that custom
code is a bad idea and decided to call this "configuration" instead, or worst of all, COTS software — without
defining what the latter term means.

Note what GAMP 5 says on this point in Appendix M4 (1): custom software components . . . , developed with an
internal scripting language, written or modified to satisfy specific user business requirements, should be treated
as Category 5. In plain English this means that the so-called configuration is really customization. Therefore, any
definition of customization needs to include the problem of the internal language customizations. So, here is my
attempt at defining these two terms.

 Configuration: The modification of the function of a software product to meet business process or user
requirements using tools supplied by the supplier. These tools can include input of user-defined text
strings for drop-down menus, turning software functions on or off, graphical dragging and dropping of
information elements, and creation of specific reports using the standard functionality of the package.
 Customization: The writing of software modules, scripts, procedures, or applications to meet business
requirements. This can be achieved using an external programming language (such as C++ or Visual
Basic for Applications or PL*SQL for database procedures), macro instructions, or an internal scripting
language specific for a commercial application.

The two definitions discussed are very important, as you will have to determine if the software you have is
customized or configured. Getting it wrong can result in generating the wrong data or receiving a noncompliance
during an inspection, as we will discuss in the next section.

Category 5: Custom Macros, Modules, and Applications

Not much has

changed in
GAMP 5 from
this apart from
the name
change from
custom
software to
custom
application.
This is the
highest risk
software, as it
may be unique
and may not be
subject to the
same rigors of
specification
Some further background reading on Wikipedia and testing as
commercial
products because it could be undertaken in-house or outsourced to a commercial software company.
However, does the name of this category really reflect the situation? The problem with this category name is the
use of the word application. This implies a single application but this does not reflect the whole reality. As GAMP
5 notes (1), software is a continuum and therefore you can have a configurable product that has custom software
or custom modules written to aid functionality of the installed application. A LIMS is a case in point here; there is
a language provided by the LIMS vendor to change the software function — this is category 5 software as
discussed in the previous section and the output is custom code. Note that the LIMS marketing people will have
you think that it is configuration. No, it is custom software as it uses an internal scripting language.

This software category implicitly includes macros written say within a spectrometer application to produce a
shortcut for processing or manipulating data; these macros are custom software and not an application per se.
Each macro needs to be validated and controlled to ensure that it does what it is supposed to do. Also, we have
in this software category the user-defined programs written on category 2 instruments; again each will be
validated.

Therefore each application, module, user-defined program, or macro needs to be specified, version controlled,
built, and tested (including integration testing with the commercial application, as applicable) as a minimum to
ensure the quality of the software. Furthermore, the custom code modules will need to have their source code
managed and backed up to prevent overwriting or loss, respectively.

Users and the Software Screwup Factor

Let us return to the discussion on software classification from a slightly different perspective. At this point I would
like to introduce you to a rather vile and obnoxious four-letter word. The word is user. We now enter the realm of
the user (defined as either someone in the laboratory or IT — I'm not fussy here) who has a multitude of
possibilities to screw up software and also the analytical results generated by it. So we'll take another look at the
GAMP software categories from the perspective of the ability of the user to change the operation of software and
hence influence, manipulate, or screw up the results.

 Category 1: The ability of users to influence results with infrastructure software is the lowest of all five
software categories. Software in this category can evolve through patching, service packs, and the
occasional new version but there is not validation in the classical sense. So instead of validating a
steady state, one qualifies each upgrade. Furthermore, the layered structure here ensures that there is
no or only an isolated impact on the data due to bugs or mistakes. So the ability of the users to influence
results is typically limited to "does the software work or not."
 Category 2: Traditional firmware is similar to category 1 software in that the instrument's operations are
fixed and the users cannot change the functions. Therefore, the screwup factor is relatively low and
hence the risk to the data. However, user-defined programs are different and will be discussed under
category 5, as there is a larger risk for incorrect data generation.
 Category 3: With category 3 software we start to enter specialized rather than general software
applications. Here software is used virtually as installed with only the run time configuration that can be
changed by the user. As there are relatively few changes to be made to the software — perhaps where
the data and records are stored being the most critical — the risk is greater than the last two categories
but still relatively low.
 Category 4: In this category there is a wider spectrum of configuration tools available to the users —
both trained and untrained in their use — and hence the screwup factor rises accordingly. With the most
configurable systems here the risk rises to a medium level. However, with more sophisticated
configuration tools the risk increases, as more mistakes can be made. Alternatively, to reduce the
screwup factor, use the software with as many default settings as practicable.
 Category 5: Here is the software category in which the user screwup factor is at its highest and the
impact of errors the greatest. There must be proper and effective controls in place for the overall
validation of the macros, modules, and applications to prevent users from doing anything stupid.
However, useless users can be told by clueless management to cut corners in the name of speed and
efficiency and not to fully specify or test the software. As custom software can contain data handling
routines, these could act unpredictably or errors could be introduced that change data and records in
subtle and undocumented ways that have not been considered due to poor specifications. Hence the
need for control of the overall process.

Let's summarize the impact of users on software. The further down the software classification you go, the
software becomes more specific in function coupled with the ability of the software to directly influence the data
and calculations and hence the final results. Or in other words, the ability of the users to screw up the software
and the data increases as you get further down the software categories. Therefore, controlling and regulating the
ability of users to configure or customize software is the key here. From a personal perspective, avoid writing any
software unless there is a good business case for doing so. My rationale is that your function in the laboratory is
analytical science, not software development.
A Modified Software Classification

Table II: Modified software classification

So if you have been following the discussion so far we need to revise the GAMP 5 software categories to take
account of the world in the laboratory. Presented in Table II is my modified classification of revised software
categories, which is a combination of GAMP 4 with GAMP 5 classifications for the laboratory that is intended to
be pragmatic and usable while managing risk effectively.

First, we return to five categories of software but use or modify, in one case, the GAMP 5 titles for them. The five
categories are shown in Table II together with the types of software examples found in each one.

Second, let us review each of the categories to see if and how they have been modified:

 Category 1: Use existing GAMP 5 classification — no changes proposed.

 Category 2: Firmware — this category has been reinstated for many laboratory instruments to make the
software classification congruent with the qualification approach in USP <1058> for Group B
instruments. However, care must be taken with some systems that allow user-defined programs to be
written; these must be validated and controlled separately in addition to the basic instrument
qualification.
 Category 3: Use existing GAMP 5 classification — no changes proposed.
 Category 4: Use existing GAMP 5 classification — no changes proposed.
 Category 5: Modify the name to Custom Modules and Applications and expand the scope to be more
explicit regarding what constitutes custom software, especially in a laboratory environment.

Summary

We have reviewed the GAMP 5 software categories and highlighted where there are strengths in the changes but
also noted the problems with some of the categories from the laboratory perspective. I have also suggested an
alternative classification that would benefit the laboratory and reinstate category 2 software. As with all my
writing, the ideas and suggestions in this column are to get you to think, adopt, adapt, or reject as you see fit.

Acknowledgment

I would like to thank Lajos Hadju for his very helpful review and constructive comments during the preparation of
this column. It was his input on the software classification and the impact of the users that has improved the
content of this column.
R.D. McDowall is principal of McDowall Consulting and director of R.D. McDowall Limited, and "Questions of
Quality" column editor for LCGC Europe, Spectroscopy's sister magazine. Address correspondence to him at 73
Murray Avenue, Bromley, Kent, BR1 3DJ, UK.

References

(1) Good Automated Manufacturing Practice Guidelines version 5, International Society for Pharmaceutical
Engineering, Tampa, FL, 2008.

(2) Good Automated Manufacturing Practice Guidelines version 4, International Society for Pharmaceutical
Engineering, Tampa, FL, 2001.

(3) United States Pharmacopoeia Inc, <1058> Analytical Instrument Qualification.

(4) R.D. McDowall, Spectroscopy 24(4), 20–27 (2009).

(5) Food and Drug Administration, Glossary of Computerized System and Software Development Terminology,