Product life cycle approach for validation of computer
systems
Validation Master Plan
Best Practice
Validation Master Plan
for Equipment, Computer Systems, Networked Systems and
Spreadsheet Applications
May 2012A master plan published for
www.labcompliance.com
Global on-line resource for validation and compliance
Copyright by Labcompliance. This document may only be saved and
viewed or printed for personal use. User may not transmit or
duplicate this document in whole or in part, in any medium.
Additional copies and other publications on validation and
compliance can be ordered from www.labcompliance.comWhile every
effort has been made to ensure the accuracy of information
contained in this document, Labcompliance accepts no responsibility
for errors or omissions. No liability can be accepted in any
way.
Labcompliance offers books, master plans, complete Quality
Packages with validation procedures, scripts and examples, SOPs,
publications, training and presentation material, user club
membership with more than 500 downloads and audio/web seminars. For
more information and ordering, visit
www.labcompliance.com/solutions
Contents
31. Purpose and scope of this plan
32. Introduction
43. Responsibilities
74. Related documents
75. Products/processes to be validated and/or qualified
86. Validation approach
107. Steps for Equipment Qualification
198. Computer System Validation
249. Networks and Networked Systems
2810. Existing (Legacy) Systems
3011. Validation of Macros and Spreadsheet Applications
3212. Change Control
3513. Instrument Obsolescence and Removal
3514. Glossary
3515. Documentation maintenance
36Appendix A. Checklists and Forms
36Checklists
36Forms
1. Purpose and scope of this plan
Provides a framework and practices for validation and
qualification of equipment, computer systems and networked systems
for laboratories and manufacturing. It also is applicable to the
validation of Macros and Spreadsheet applications. The Validation
Master plan should ensure that validations and qualifications are
done efficiently and consistently throughout the organization and
meet regulatory, quality and business requirements. The plan should
ensure that the company's validation procedures are followed. The
company validation master plan is the basis of individual project
validation plans, sometimes also called master validation plan.
2. Introduction
This is the most important part of a validation plan. It
summarizes what the project is all about and what you are trying to
accomplish with it and with validation. It summarizes
The purpose of project
Brief description of the system
Validation approach
The name and location of the facility where the equipment or
system is located
Timeline
3. Responsibilities
Identifies all validation responsibilities like system owner,
system manager, validation team, QA, operations, plant
maintenance/engineering, IT, lab support services, users etc.
3.1 Validation team creates, updates, and reviews/ approves
individual project validation plans and validation deliverables
ensures validation compliance with the company validation master
plan and project validation plan
coordinates, implements, verifies elements of the VMP
consults on, evaluates and approves changes
reviews and approves IQ/OQ/PQ procedures and plans
reviews test results and makes recommendations regarding
release
assess risks and develops contingency plan
3.2 User representation
create and maintain equipment inventory
makes a proposal for specifications(user requirements,
functional specifications)
provides resources for all required qualification activities
(IQ, OQ, PQ)
reviews procedures test methods for usability and
practicability
recommends criticality level of failures
monitors on-going system performance and reports problems
3.3 Plant safety/maintenance/engineering
advises on and prepares the facility/laboratory to meet the
equipment's environmental and safety specifications
3.4 Information Services (IS) assures that selected system fit
into current and future IT infrastructure
performs installation and maintenance of computer networks
provides tools for data collection and archiving
provides training for users on the use of networks
3.5 Validation (engineering) groups provides expertise to
develop and implement validation deliverables in efficient and
consistent way
provides detailed validation guidance
trains employees on validation requirements and techniques
3.6 Quality Assurance (QA)
provides quality assurance expertise in the creation of the
project validation plan and other validation deliverables
monitors compliance with regulations and established
standards
approves and administrates SOPs
audits equipment/computer systems
develops test plans for equipment and computer systems(This can
also be done by the development department. In this case QA reviews
the plans)
leads vendor assessment program
trains employees on regulations
3.7 Responsible person
manages the validation project
establishes a project validation team
schedules and facilitates validation team meetings
initiates creation and maintenance of documentation
assures that change(s) are managed and controlled
assures the final approval of the system for use
keeps information on all validation activities
informs all parties on changes
3.8 Consultants
Some of the activities can be out-sourced to consultants. For
example, developing specifications based on inputs from users,
developing IQ/OQ/PQ procedures, leading vendor assessment programs
and preparing validation summary reports
3.9 Vendors
Design, develop and validates equipment, software and systems
during development following documented procedures
Provides documented evidence that the software has been
validated
Provides documentation on the validation approach taken by the
vendor
Provides a complete list of functional and performance
specifications that can be used to derive a company's specification
for the project
Allows a vendor audit if required by regulatory agencies or the
user
Provides documentation and services for installation
qualification
Provides documentation and services for operational
qualification
Provides training on the technique and operation of the
system
Provides on-going support through phone or on-site
3.10 All
Assure that all people who are involved in the specification,
design, development, validation and use of equipment and
computer/networked systems are trained and understand
regulations.
4. Related documents
Corporate and/or local validation policies
Standard operating procedures
Checklists, e.g., for vendor assessment
Templates, e.g., for change control
5. Products/processes to be validated and/or qualified
5.1 Equipment, computers, software, network modules and
networked systems that are used in regulated environment.
Requirements may come from the US FDA and EPA, EU authorities,
Japanese MHW or any other country that may have an impact or the
companies business.
5.2 Equipment, computers and networked systems and software that
are critical to the operation of a company or department
5.3 New equipment, computers and networked systems
5.4 Existing equipment, computers and networked systems
5.5 Any computerized system that is used to create, modify,
maintain, archive, retrieve or transmit data (US FDA 21 CFR Part
11). This includes, for example, analytical instruments, other
automated laboratory equipment, computers that are used to acquire,
and evaluate data and Laboratory Information Management Systems
(LIMS). It also includes systems to create and maintain Standard
Operating Procedures (SOP) in electronic format, Calibration
Tracking Systems (CTS), and may be e-mail systems. Other examples
are Supervisory Control And Data Acquisition (SCADA), Electronic
Batch Record Systems (EBRS), Programmable Logic Controllers (PLC),
Process Control Systems (PCS), integrated information/business
Systems, Enterprise Resource Planning (ERP) Systems, , Digital
Control Systems (DCS), Systems, Manufacturing Execution Systems
(MES) and Laboratory Information Management Systems (LIMS).
Ask yourself, if the information on the system is absolutely
required for GMP/GMP. If yes, the system should be validated.
5.6 Equipment and computers/networked systems as identified in
chapter 5.5 after changes.
6. Validation approach
Approach for new systems
6.1 If the equipment/computers are used across more than one
department, form a project validation team representing all
affected departments. Expertise of any of the department is needed
for doing initial validation 'right' but also for revalidation when
the system is changed.
6.2 Develop a validation project plan with time schedule and
owners
6.3 Develop user requirement and functional specifications
6.4 Select a supplier (may be internal or external)
6.5 For computer systems, qualify the supplier (for details, see
chapter 7)
6.6 Develop validation procedures (SOPs) and templates that can
be used to qualify or validate the system during installation (IQ),
prior to operation (OQ) and during routine use (PQ).
6.7 Develop criteria and procedures for
revalidation/requalification
6.8 Develop acceptance criteria for OQ and PQ tests.
6.9 Get approval for test procedures and acceptance criteria
from QA and the validation team.
6.10 Install the system and perform IQ
6.11 Perform and document OO tests
6.12 Check if criteria under 6.8 are met
6.13 If acceptance criteria are not met, check
equipment/computerized/networked systems or procedure. Acceptance
criteria should not be changed. Repeat steps 6.11 and 6.12. If the
problem still exists, report to the supplier.
6.14 Write an OQ summary report.
6.15 Implement procedures for on-going performance qualification
(PQ).
6.16 The validation/qualification documents should be reviewed
and approved by the validation team, the system owner, e.g., the
lab manager for small systems, QA/QC and other departments if,
affected, for example, IT departments, for networked computer
systems. Changes to the documents should be approved and documented
(versioned).
6.17 All validation/qualification documents should be archived
in secure locations
Approach for existing systems
When the FDA or other regulatory agencies audit computer
systems, they will not ask if the system is new or legacy (legacy
means, the system has been in place before a new regulation has
been released). They will ask for a validation approach and expect
to have similar or the same documents available as for new systems.
The following steps demonstrate the approach the company takes to
bring legacy systems into the validated status.
6.18 Develop an inventory (master lists) that includes all
equipment and computers currently in use in the
laboratory/operation and appropriate business area. The inventory
list should be designed such that it can easily be upgraded.
6.19 Categorize the equipment and computers based on impact to
regulatory submission and business impact, use yes or no. (yes =
requires validation, no = does not require validation)
6.20 Further identify impact on product quality of all equipment
as classified in 6.19 with 'yes'. Use categories high (immediate
impact on product quality), medium (no immediate impact on product
quality), low (no impact on product quality)
6.21 Develop a time plan to validate the selected systems using
classification in 6.20 as criterion. Immediately start to validate
all systems classified as "high"6.22 For further steps, follow 6.1)
to 6.17).
7. Steps for Equipment Qualification
Equipment qualification should include:
7.1 Design Qualification (DQ)
DQ defines the functional and operational specifications of the
instrument and details the conscious decisions in the selection of
the supplier. DQ should ensure that instruments/computer systems
have all the necessary functions and performance criteria that will
enable them to be successfully implemented for the intended
application and to meet business and regulatory requirements.
Inputs for specifications come from anticipated users. Design
qualification should include these steps: Background information
and description of the application problem. If the instrument will
be used for several applications, describe a few typical
scenarios.
Selection of the technique and/or type of equipment
Description of the purpose and intended use of the equipment. If
the instrument will be used for several applications, describe a
few typical scenarios.
Description of the intended environment
Description on how the instrument will be used in the selected
environment and within a process. If the instrument will be used
for several applications, describe a few typical scenarios.
Development of user requirement specifications
Preliminary selection of the functional and performance
specifications (technical, environmental, safety, security access,
compatibility with existing and future systems/platforms)
For larger systems, development of system schematics, network
layouts etc
Preliminary selection of the supplier
Instrument tests (if the technique is new)
Final selection of the equipment
Final selection and qualification of the supplier and
equipment
Discussion and documentation of warranty, familiarization,
training, consulting and other vendor services
Development and documentation of final functional and
operational specifications
Review and approval of user requirement and functional
specifications by users of the system and by the project validation
team.
7.2. Installation Qualification (IQ)
Installation qualification establishes that the instrument is
received as designed and specified, that it is properly installed
and configured in the selected environment, and that this
environment is suitable for the operation and use of the
instrument.
Installation Qualification should include these steps:
Check if the environmental and safety conditions, e.g., power
condition requirements, meet the criteria as specified for the
instrument
Compare equipment, as received, with purchase order (including
software, accessories, spare parts)
Check documentation for completeness (operating manuals,
maintenance instructions, standard operating procedures for
testing, safety and validation certificates)
Check equipment for any damage
Install hardware (computer, equipment, fittings and tubings for
fluid connections, power cables, data flow and instrument control
cables)
Switch on the instruments and ensure that all modules power up
and perform an electronic self-test
Install software on computer following the manufacturers
recommendation
Verify correct software installation, e.g., verify that are all
files loaded. Utilities to do this should be included in the
software itself.
Make back-up copy of software.
Configure peripherals, e.g. printers and equipment modules.
Identify and make a list with a description of all hardware,
include drawings where appropriate.
Make a list with a description of all software installed on the
computer.
List equipment manuals and SOPs.
Develop operation and calibration procedures.
Make entries into the equipment logbook.
Prepare an installation report.
Enter the equipment in the laboratory's equipment database
Items that should be included for each piece of equipment in the
database include:
Unique in-house identification number (asset number)
Name of the item of equipment
The manufacturers name, address and phone number for service
calls, service contract number, if there is one
Serial number and firmware revision number of equipment
Date received
Date placed in service
Current location
Size, weight
Condition when received, for example, new, used,
reconditioned
List with authorized users and responsible personThe database
should also have entry fields for dates of the last and next
operational qualification.
For large systems, e.g., computerized protein sequencers, IQ
should be performed and documented by the supplier. The user should
sign the IQ report. For small equipment, e.g., pH meters, IQ should
be performed and documented by the user.
IQ documents must be updated, if there is any change to the
system. Changes can include:
move to an other room
update with new hardware, firmware, software
exchange of modules which have individual serial and/or asset
numbers
7.3. Operational Qualification (OQ)
Operational qualification (OQ) is the process of demonstrating
that an instrument will function according to its operational
specification in the selected environment. The instrument should be
tested against critical performance specifications as specified in
the Design Specifications document.
Steps for OQ include:
Obtain functional and performance specifications (preferably use
information from DQ).
Identify critical functions that should be tested in the user's
environment.
Link the test cases to the user requirement and functional
specifications as defined in the DQ phase.
Develop SOPs for testing
Test procedures should include what to test, how testing should
be conducted and the expected results with acceptance criteria.
For modular systems, test the system as a whole, not module by
module
If there are several systems of the same type and function in a
laboratory/operation, use the same procedure and preferably the
same acceptance criteria for all systems
Whenever possible use the manufacturer's procedure for
testing
Don't use the manufacturer's performance specification limits if
the performance is expected to deteriorate over time. Take
performance specification as required by the application.
Decide for each instrument whether to do OQ tests by your own
people, by the vendor or by a 3rd party. Criteria are costs,
availability and training of people and available of (traceable)
qualification tools.
Define the frequency of OQ as recommended by the vendor.
Define re-qualification criteria and procedures after equipment
up-dates, moves and repairs.
7.4. Performance qualification (PQ)
Performance Qualification (PQ) is the process of demonstrating
that an instrument consistently performs according to a
specification appropriate for its routine use. Important here is
the word consistently.
Main activities in the PQ phase are
preventive maintenance
requalification after changes and
on-going tests.
The test frequency is much higher than for OQ. Another
difference is that PQ should always be performed under method
conditions that are similar to routine sample analysis.
In practice, for laboratory operation PQ testing can mean system
suitability testing, where critical key system performance
characteristics are measured and compared with documented, preset
limits. For example, a well characterized standard can be injected
5 or 6 times and the standard deviation of amounts are then
compared with a predefined value. If the limit of detection and/or
quantitation are critical, the lamps intensity profile or the
baseline noise should be tested. Recommended steps for PQ are:
1. Define test procedures and the performance criteria for the
complete system.
2. Select critical parameters. For a chromatography system this
can be
precision of the amounts
precision of retention times
resolution between two peaks
peak width at half height or
peak tailing
limit of detection and limit of quantitation
wavelength accuracy of a UV/Visible wavelength detector.
3. Define the test intervals, e.g.,
every day
every time the system is used
before, between and after a series of runs
4. Record any unusual event in the equipment logbook
5. Define corrective actions on what to do if the system does
not meet the criteria, in other words if the system operates out of
specification.
7.5. Documentation
On completion of equipment qualification, documentation should
be available that consists of:
Validation summary report with final approval (disapproval)
statement, the qualified operating ranges, and a list of all
deliverables generated during the validation process. The report
should also contain a list of follow-up activities if there are
some deviations.
Design qualification documents with purpose of the system, user
requirements and functional and performance specifications.
Installation qualification document (includes description of
hardware and software).
Procedures for OQ testing and acceptance criteria.
OQ test protocols and results with signatures and dates
PQ test procedures, acceptance criteria, test protocols and
representative results
OQ stickers for the equipment with information on test engineer,
date of OQ and date next OQ
Statement by the user on formal acceptance
Updated equipment database with information on validation
status.
8. Computer System Validation
In principle validation of computer systems should follow the
same guidelines as outlined in Chapter 7 for equipment
qualification. If the computer is connected to equipment and used
for instrument control and data evaluation for that equipment
without networking to other computers, the computer can be treated
as a module of that system and should be qualified as part the
system.
For networked computer systems with more complex functionality
additional tasks should be performed for the individual
qualification steps (see also next chapter).
8.1 Design qualification
DQ should include a background information and a description of
the current computer system platform, future plans and how the new
system fits into this environment. It should describe which role
the system plays in the workflow of an overall process. This
includes interfaces to equipment but also to a corporate IT system.
Once the workflow and data flow known, there should be a
definition
of raw data and meta data,
how integrity of the data is ensured
for how long these data must be archived and
how they can be retrieved.
DQ should also describe whether the system will be configured or
otherwise customized in the user's environment. If the system is
purchased from a vendor and customized by the user, it should
clearly describe who is providing what.
When documenting communication between equipment and the
computer, the user requirement and functional specifications should
clearly state if it is a one-way or two-way communication and how
many instruments can communicate with the computer simultaneously.
8.2 Vendor qualification
For computer systems there should be documented evidence that
software and system has been validated during and at the end of
development. The vendor should also provide assistance for DQ, IQ
and OQ and on-going support during routine use. The user must have
confidence in the supplier's quality, validation and support
processes that should be documented in a formal vendor assessment
document. There are different possibilities to assess a vendor.
They are listed in table 8.1. Table 8.1 Possibilities to assess a
vendor
#AssessmentComment
1Through references outside your companyUseful if there is no
experience with the vendor within your company. Criteria are
acceptance of the vendor in the market place
image of the vendor as software supplier
quality reputation of the product
2Through own experience with the vendorExperience may come from
the product under consideration or from other products. Criteria
are
Quality of the products (failure rate)
Responsiveness in case of errors(phone call, on-site visit, bug
fix)
3Through own experience with the productVery much the same as in
2, but more accurate because most likely the software has been
developed and is supported by the same people as the new
purchase
4Checklist - Mail auditUse checklists available within your
company, through public organizations, e.g., PDA and from private
authors, e.g., in this book
5Follow up through video or teleconference Can be used to proof
that documents referred to in the mail audit exist, are readily
available and have required content and quality
6Assessment through 3rd party auditsGive an independent
assessment of the quality system and/or product development
7Vendor audit through user to assess the quality systemGives a
good picture on the vendors quality system
8Vendor audits through user for individual projects Gives a good
picture on how the quality of the individual product
The required assessment level depends on the complexity of the
system and should be defined by the project team and documented in
the individual project validation plan.
The vendor should be qualified based on business aspects (size,
market focus, financial strengths, attitude to people
qualification, future perspective) and technical aspects
(specification, design, development, testing and support).
Key elements of a vendor assessment are:
The vendor must provide documented evidence that the software
has been validated during development. This can include a
validation certificate and a description on the vendor's
development and validation procedure. The vendor should also agree
to provide access to additional information like test plans, test
results or source code at the vendor's location.
The vendor should have procedures and/or systems in place for:
security, maintenance, user feedback, change control, backup and
disaster recovery system to ensure safe ongoing support of the
system.
All people in software development should be adequately trained
on software engineering practices but should also have a basic
understanding on regulatory requirements, e.g., GLP and GMP.
Customer support people should be available on the phone and for
on-site visits, if need arises.
Depending on the criticality and complexity of computer system,
the assessment can be based on historical experience with the
vendor, checking the documentation as provided by the vendor,
developing and evaluation of additional questions/answers and
finally through a vendor audit.
A vendor assessment or qualification report should be developed
which includes a statement on 'vendor qualification status'.
Depending on the complexity and information existing on a vendor
a direct audit can be necessary. The validation team should decide
on this for each individual project.
Criteria for a vendor audit are:
Commercial off the shelf system or be-spoke
Complexity of the system
Number of systems purchased from the vendor
Availability of development validation from the vendor
Stand alone or networked system
Influence of the system on other systems
Maturity of system
Experience with the system
Reputation of the system in the market place
Experience with the vendor
A vendor's documented evidence of audits from other companies
within the same industry?
Own audit experience with the vendor
Business impact of the system
8.3 Installation qualification
IQ should include a test to verify that the software has been
copied accurately and completely to the computer's hard disk.
Preferably the vendor should provide such verification programs as
part of the application software.
For complex computer systems, a schematic diagram should be
developed to illustrate the individual hardware connections and the
data flow.
Verify correct use of cables as specified by the vendor, for
example type and length.
Computers should be entered in the equipment inventory database.
Information should include
Computer hardware with information on the processor, hard disk
space, memory and the monitor
Software with product and revision number
8.4 Operational qualification
Most important for OQ testing of computer systems is the right
selection of tests. It is obvious, that not all functions can be
tested. Selection of tests should be based on risk assessment and
must be approved by the validation team.
OQ should also include specific tests to meet requirements of 21
CFR 11, e.g., limited system access, electronic audit trail,
generation of exact copies, prevention of overwriting raw data when
reprocessing data.
If multiple analytical instruments are connected to single
computers, proper function and correct data transmission should be
verified under the highest anticipated data transfer rate (high
load testing).
If the computer system is expected to perform multiple tasks
simultaneously, proper function should be verified under highest
anticipated workload.
Tests cases and acceptance criteria should be traceable to
specifications. Test data sets and procedures should be designed
such that they can be easily re-used for later requalification.
8.5 Performance qualification
Performance qualification should include
regular virus checks
regular data backup and removal of unnecessary files to avoid
hard disk overflow. As a rule of thumb, the hard disk should not be
loaded more than 80%
procedures and regular check for authorized user access
procedure and regular problem reporting system back to the
system developer 9. Networks and Networked Systems
In principal networked systems and applications running on
networks are computer systems and as such should follow practices
for computer system validation. Everything what is important about
computer validation can be applied to networks as well. A network
component should be treated like a piece of equipment, which is
installed and qualified. As next typical network functions such as
limited access and network transactions should be qualified. As the
final step the complete network application should be tested and
test results compared with specifications.
Compared to standalone computer systems, networks and networked
systems require some special considerations for all qualification
phases:
9.1 Design qualification
When a network is specified, the following questions should be
answered:
How much traffic will it carry, especially under highest load or
under so called worst case conditions?
What is the maximum distance between individual network
components?
How many users are using the network concurrently?
What is the risk and impact of a server failure?
What are the backup and archiving cycles?
What availability is expected from the network?
What is the environment in which it will be operating?
What are the protocols: GPIB-IEEE vs. TCP/IP?
For networked systems: Description of the scope of the system:
what is it, what is it not (important to define the validation
box). This is important to draw the boundaries to other
systems.
9.2. Installation Qualification
Network specific IQ activities include:
Configure and document all network settings (e.g., routers
settings).
Include network cables and other hardware components, e.g.,
hubs, and software into the equipment data base.
Check if physical security specifications are met (e.g.,
lockable hardware to prevent unauthorized access to the server's
RAID system).
Develop high level and detailed system drawings, physical
diagrams such as floor plans with component locations and cabling,
and logical diagrams like TCP/IP schemes and how components
interrelate with each other.
9.3 Operational Qualification
Network specific tests should include
Starting and shutting down networked systems (including
documenting messages indicating whether the network was
successfully started/shutdowned)
Switching of and on network components (e.g., hubs, routers,
switches) and to note the impact of the action on the network
capability to operate.
Security tests, for example logging on with correct and
incorrect password.
Checking correct password administration, for example, when the
password policy says that a password should have a minimum length
of six characters, try to specify one with four characters.
Checking session unlock and user specific automated time-outs,
if there are any.
Checking access to task and file permissions. For example, if an
operator has permission to review data, try to modify them and see
if the system behaves as expected.
Checking correct backup and restoration of data.
Checking how the system behaves and recovers from system
failures. Trigger a failure through disconnecting and reconnecting
network components.
Checking correct audit trail of network transactions.
Checking correct data transfer under normal AND under high
traffic. Checking individual software modules and systems for virus
infection9.3 Performance Qualification
Develop and implement procedures for back-up and retrieval. The
frequency should be based on risk assessment and be defined by the
validation team.
Validate back-up and retrieval procedures.
Develop and implement a contingency plan for failures of network
components to avoid loss of data.
Review of network diagrams.
Verify individual software modules and systems for virus
infection.
9.5 Documentation
Network specific documentation should include
Network drawings.
Updated glossary with network terminology
Updated equipment data base with network hardware, firmware and
software
Procedures to control network security in general
Procedures for generation, distribution and use of passwords
Procedures for back-up and contingency planning
Network configuration management
10. Existing (Legacy) Systems
Existing equipment and computer systems should be qualified
and/or validated. The same principles apply as for new systems. As
explained in the preamble of FDA's 21 CFR Part 11 does not
grandfather legacy systems and FDA expects that firms using legacy
systems will begin taking steps to achieve full compliance. Firms
should have a reasonable timetable for promptly modifying any
system not in compliance (including legacy systems) to make them
Part 11 compliant, and should be able to demonstrate progress in
implementing their timetable. FDA expects that 21CFR Part11
requirements for procedural controls will already be in place. FDA
recognizes that technology based controls may take longer to
install in older systems
The main difference to new systems is that typically no
information on the development process is available. Instead, there
is lots of knowledge from past experience. This experience should
be used to proof correct function and performance. Develop an
equipment master plan that lists all equipment and computer systems
together with a judgment for validation need. Develop an
implementation plan with a time schedule for the validation of all
systems. Validation should follow the same steps as for new
systems.
10.1 Design qualification
Describe the use of the systems.
Describe required functions and performance.
No vendor qualification or evidence of development validation is
required.
10.2 Installation qualification
Document system hardware and software and enter equipment data
into the laboratory's database.
10.3 Operational qualification
Evaluate which tests have been done in the past and check if
they are sufficient to proof operational qualification
If not, develop test procedures and acceptance criteria.
Execute and document test and compare test results with
acceptance criteria.
Declare the system as validated.
10.4 Performance qualification
Follow steps as described in chapter 7 and 8.
11. Validation of Macros and Spreadsheet Applications
Macro programs and spreadsheet calculations are considered to be
software and should be validated to demonstrate suitability for
their intended use. The extent of validation depends on the impact
of the Macro on product quality and on the complexity of the Macro.
Any step can be passed over as long as there is sufficient
explanation that the skipped step has no relevance for the program.
The validation steps should include:
11.1 Develop a project validation plan
Defines the scope of the project, responsibilities, validation
approach and timeline and it includes checkpoints.
11.2 Define responsible persons
Identify persons responsible for specifications, design,
development, tests, and approvals.
11.3 Define user requirements
Describe the task, how the task is done currently and how the
new program will do it more efficiently. Describe user requirements
(what the user wants to do with the system), system requirements
(computer hardware, operating system), regulatory (GLP/GMP/GCP, 21
CFR Part 11) requirements and security requirements. Describe the
user's current environment: hardware environment, software
environment, IT environment. Specify minimum hardware and software
requirements that will be used. Describe the required skill level
of the end users. Describe how extensively and how long the
software is intended to be used (anticipated number of users, life
time, frequency of use) and whether any changes are anticipated
during the life of the program.
11.4 Specify Functions
Describe the program in terms of the functions it will perform,
written in such a way that it is understood by both the software
developer and the user. Review the functional description against
the requirement specifications
11.5 Design and implementation
Document formulae or algorithms used within the program. Write
the code. Define file structure, e.g., whether to use one Excel
workbook with multiple sheets, several single-sheet workbooks or
just a template. Define formulas to perform calculations. When
using Excel, define whether to use Excel functions or VBA
procedures. Determine the most appropriate user interface: dialog
boxes, list boxes, menus, toolbars, short cut keys. Define the
level of security to restrict access to the whole or particular
elements of the program. Define how to handle errors, e.g., how the
application detects and deals with errors. Annotate the code using
documentation standards of your organization, if available Document
the program such that it can be understood by other people whose
education and experience are similar to the programmer.
11.6 Testing
Develop a test plan to test the Macro and Spreadsheet
application for all functions the user will use. Develop a matrix
that links functions to be tested to requirement specifications.
Develop test cases and test data sets with known inputs and
outputs. Describe the test environment and the execution of tests.
Test protocols must clearly state the Macro title, revision number,
and file name. Tests should describe the test environment and the
execution of tests. Develop test cases and data test sets that can
be used for current and future testing that simulate as much as
possible the real-life environment (life testing). Include test
cases with normal data across the operating range, boundary testing
and unusual cases (wrong inputs). Include procedures to verify
calculations. Test procedure and results should be documented,
reviewed and approved by the programmers, and for complex macros by
quality assurance departments.
11.7 Ongoing performance checks
Specify type and frequency of checks as well as expected results
and acceptance criteria. Develop test data sets and procedures for
ongoing performance checks.
11.8 User documentation
Describe the programs functionality and formulae used for
calculations and how to install, operate and test the program.
11.9 System security and data integrity
Describe which features are implemented to meet security
requirements, for example, back-up procedures and limited
authorized system access to the program and data. Describe how
integrity of Macro and Spreadsheet program and data generated by
the program is ensured, for example how can you ensure that only
authorized Macros are used and Macros are not changed, either
incidentally or accidentally, outside the change control
environment.
11.10 Change and version control
Develop a procedure to authorize, test, document and approve any
changes to the software before implementation.
12. Change Control
Equipment, computers and networked systems are frequently
changed during the life of the systems. It is of utmost importance
to keep systems in the validation status.
Any change to equipment and computerized/networked systems that
may affect the systems validation status should follow documented
procedures and should be formally approved. The procedure should
include instructions for requesting, approving, documenting and
implementing changes. They should also describe the method of
evaluation to determine the degree of revalidation or
requalification necessary to maintain the validated state of the
system. The procedure should also identify the persons responsible
for determining the necessity for change control and for
authorizing the change.
If changes are made within a complex computerized/networked
system, the project validation team consisting of users of
equipment, support personnel and computer validation experts should
evaluate the need, type and extend of re-qualifications on a case
by case basis. The user of the system should get advice from the
computer validation experts on which impact the change may have on
her/his system and which type tests should be done.
If a vendor changes the software the new release should be
shipped to the users site with a validation certificate to
demonstrate that the update has been developed and validated at the
vendors site to appropriate standards. The vendor should also
inform users if the new software may have an impact on Marco
programs the user has written.
The vendor should provide a list with functions that have been
changed, added or deleted and with information on which impact the
changes have on the validation status.
At the users site the system with the new software revision
should undergo formal installation qualification (IQ) as for a new
system.
The validation team should evaluate the need for OQ testing.
Where possible, the test cases test data used for the
re-qualification should be designed so that the results can be
compared with those obtained using earlier versions.
Before the system continues with routine analysis, a performance
qualification (PQ) should be carried out. All details of the change
should be formally documented with information on:
clear identification of software or hardware to be changed
reference number of change for clear process identification
nature of the change
the reason for the change
date when the change was requested
removed software errors
new functions together with their features and benefits
impact analysis the change may have on the performance of
connected modules and systems
the impact the change may have on user contributed Macro
programs
the type of revalidation or re-qualification tests based on the
impact analysis
acceptance criteria and
test results
revision history with old and new version numbers
date when the update was installed
list of people who have been informed
13. Instrument Obsolescence and Removal
When instruments are retired, a plan should be in place to
ensure that the application can run on the new system and data
generated on the old system work on the new instrument.
Steps include
Transfer the application, e.g., analytical methods, raw data,
analytical results and databases to the instrument.
Check if the new system generates the same results from raw data
as the old system.
14. Glossary
For an extensive glossary on qualification and validation see:
www.labcompliance.com/glossaryThe glossary also includes
terminology for network hardware and software.
15. Documentation maintenance
Lists all documents
Describes where documentation and software is archived.
Describes criteria and examples for time the documentation must
be archived: examples include validation master plans, project
validation plans, validation deliverables, user manuals
Defines owners of documents
Appendix A. Checklists and Forms
Checklists
Forms
F1001 Change control form
F1002 Change control summary log
F1004 Initiation and authorization of Macros and
Spreadsheets
F1006 Validation deliverables and owners
F1009 Validation team members
F1010 Preparation and approval of the validation master plan
Form F1001: Change control
Change Control Form
Form ID
Date:
System ID:
Location:
Description of change (should include reason for change)
Expected impact on validation
Authorization to change
Name: Signature Date
Change implemented on Date:
Comments (implementation, testing)e.g., document any observation
and new version or revision number, types of tests that have been
performed
Completed byName: Signature Date
Approved byName: Signature Date
Form F1002: Change control summary log
System IDName: CDS ChemStation Plus Number: C4663B
DateType of ChangeChange control form ID
04/75/01ChemStation software upgrade from version A.08.01 to
A.08.01H1674
Form F1004: Initiation and Authorization of Macros &
Spreadsheets
Form ID
System Location:
Initiator:
Description of problem, how it is solved now and how the new
software can improve efficiency
Expected duration of use and frequency of use: e.g., 6 months, 5
times a day
Approval of supervisor:
Supervisor function:
Name Signature Date
Comments:
Approval/rejection by QA:Approval yes/no
Reason for approval/rejection
Name Signature Date
Comments/Recommendations:
Form F1006: Validation deliverables and owners
DeliverablePrepared by Reviewed by Approved by
Referencedocument
Validation plan
Validation teamOperation managerQA system OwnerVP 679
IQ Protocol
VendorValidation teamQA managerV456
Form F1009: Validation team members
DepartmentNameTelE-mail
QA
Consultant
IT
Lab
Validation group
Vendor
Form F1010: Preparation and approval of validation project plans
(master validation plan)
Preparation
Representing department Name
SignatureDate
User
QA
IT
Validation group
System ownerBusiness Management
Review and approval
Representing department NameTitle
SignatureDate
System Owner/Management
QA Compliance
www.labcompliance.com Page 12 of 12