Beruflich Dokumente
Kultur Dokumente
Conflicts of interest
Robin Nozick declares that she is an Executive of a company which performs Validation and other Quality Management
Services for Clinical Laboratories and Transfusion Services. All other authors have declared no conflicts of interest.
Contents
Introduction i
Acknowledgements ii
1. Overview 1
2. Purpose 1
3. Scope 1
4. Responsibility 1
5. Change control 2
5.1 Project change control 2
5.2 Operational change control 2
5.3 System inventory 2
6. Validation process throughout automated system lifecycle 3
6.1 Start up of validation 4
6.2 User Requirements Specification (URS) 4
6.3 System selection 4
6.3.1 URS review 4
6.3.2 Supplier qualification 4
6.3.3 System evaluation 4
6.3.4 Financial considerations 5
6.4 Risk assessment 5
6.5 Validation plan 5
6.5.1 Validation approach and content of the validation plan 6
6.5.2 Validation protocols 7
6.6 Data migration 7
6.6.1 Plan 8
6.6.2 Execute and report 8
6.6.3 Perform migration verification 8
6.7 Infrastructure qualification 9
6.7.1 Servers and hosts 9
6.7.2 Network infrastructure 9
6.7.3 Clients 10
6.8 Training 10
6.9 Testing 10
6.10 Business continuity plan 10
6.11 Problem resolution 11
6.12 Validation report and final review 11
6.13 Handover (go-live) process 11
6.14 Validation state maintenance 11
6.14.1 Calibration and monitoring 12
6.14.2 Preventative maintenance 12
6.14.3 Software patches ⁄ service packs installation 12
6.14.4 Training and competency 12
6.14.5 Suppliers re-qualification 13
6.14.6 Periodic review 13
6.14.7 Performance monitoring 13
6.14.8 System retirement 13
7. Security 13
7.1 User access policies 14
7.2 System access policies 14
8. Back-up and recovery 14
9. Archive and record retention 14
10. References 14
11. Reading list 15
12. Acronyms 15
13. Glossary 16
Appendix 1 Documentation 18
Appendix 2 Classification of automated systems 19
ISBT Science Series (2010) 98 (Suppl. 1): 1–19
ª 2010 ISBT, VOX Sanguinis (2010)
ORIGINAL ARTICLE
1
2 Guidelines
The validation team may include validation specialists, library files, configurable packages, drivers and compil-
quality assurance staff, operational users, information tech- ers;
nology staff, engineering staff, suppliers, purchasing staff • configuration files ⁄ reference tables;
and consultants. The minimum membership of a validation • data migration files and programs;
team should be representatives of the process owner, IT and • manuals (user manuals, system manuals);
quality assurance. The actual membership will be deter- • development documentation;
mined by the scope of the validation. Within certain con- • validation documentation;
straints (e.g. personnel reviewing the validation should not • training materials;
have executed the tests they review), individuals on the val- • SOPs.
idation team may have multiple responsibilities. All valida- Modifications to system configuration and ⁄ or validation
tion activities must be communicated to or even involve deliverables resulting from test deviations encountered
the top management of the blood establishment in an ade- during the qualification phases are subject to project
quate way. change control.
The following are examples of responsibilities that may
need to be assigned to members of the validation team:
5.2 Operational change control
• management of validation process;
• preparation, execution, review and approval of valida- Changes to a live automated system are managed through
tion plan and protocols; the facility’s change management procedure. Some changes
• quality assessments of third-party suppliers; may require notification to or license amendment from reg-
• problem resolution; ulatory agencies. Operational change management should
• identification and provision of required materials and continue until system retirement.
support; All proposed modifications, enhancements or additions
• filing and maintenance of all completed validation doc- should be reviewed and assessed to determine the affect
umentation; each change would have on the system. This operation
• verification of data migration; should determine the degree of required validation. When
• development of documents including Standard Operat- changes are made to an automated system, sufficient vali-
ing Procedures (SOPs); dation should be conducted to demonstrate that portions of
• preparation, execution, review and approval of training the software not involved in the change were not adversely
plans. impacted. This is in addition to testing that evaluates the
correctness of the implemented change(s). Where required,
SOPs should be updated and user training updated and
5. Change control
delivered before implementing the changes. All other rele-
Any change occurring during a project before releasing an vant documentation should also be updated.
automated system or to an operational automated system Operational change control SOPs should allow for spe-
should be documented in order to ensure that the system is cific variation for certain types of changes such as system
maintained in a state of control. administration modifications, emergency or repair changes,
Change should be initiated and controlled by the process or for workarounds provided sometimes by the software
owner. vendor.
It is the responsibility of the system process owner to
ensure that a change contol process and procedures are in
5.1 Project change control
place that support changes to the system.
Before releasing an automated system and during the vali- It is the responsibility of Quality Assurance to ensure
dation process, modification to the configuration of the SOPs are followed.
automated system may be made to comply with expecta- It is the responsibility of each member of the change team
tions. to execute the assigned activities accurately and completely.
Any change occurring during the implementation phase
must be documented and controlled.
5.3 System inventory
All deliverables in the context of the project or system
should be identified, so the items subject to change control A system inventory should be maintained which specifies
may be defined. These include: for each critical system :
• hardware; • the owner of the system
• software: including application software, operating sys- • its validation status
tems, DBMS (Database Management Systems), firmware, • date when due for periodic review ⁄ re-validation.
Evaluation will be against criteria specified by the user their own applications by customizing ⁄ configuring the sys-
in the URS. Results of the system evaluation should be pre- tem. Each application then becomes specific to this user
sented in a report. and maintenance of the system becomes an important pro-
From the user perspective, system evaluation should be cess, especially when new updates to the system are
performed on critical automated systems that are configu- installed. Often, the configurable system is part of a much
rable, off-the-shelf packages or bespoke developments. bigger network, which in turn becomes the entire system.
This makes it impossible for the vendor to validate each dif-
6.3.4 Financial considerations ferent type of final system. The amount of testing and how
Financial considerations are an important element in the many times the same process is tested is dependent on the
selection of a new automated system. The user should con- amount of risk the functionality may present. This should
sider costs of the entire life-cycle of the system including: provide the user with a higher degree of assurance that the
• One-time implementation costs such as: system will consistently produce a quality product.
- software licensing; A systematic approach is needed to perform a thorough
- hardware, interfacing and peripheral costs; risk assessment. First, each potential risk of a system or
- data migration, installation, and training costs; subsystem is identified and traced to a trigger, event or
- validation effort needed; cause. Information regarding each potential risk is col-
- travel and lodging expenses, etc. lected, analysed and a category assigned. An example of a
• On-going costs, such as: useful categorization is in the following table.
- software support;
- hardware and network maintenance;
High Risks are considered to be Intolerable
- archiving of historic data and records;
Medium Risks are Undesirable
- frequency of anticipated software updates and system Low Risks are so low as to be Negligible
upgrades and the amount of revalidating involved;
- additional staffing in technical, quality, end user areas
etc. Next, options should be provided for risk reduction,
• Retirement costs. either to mitigate and ⁄ or eliminate the risk. It may be
decided that the risks in the system are so high, it should
not be implemented. If it is decided to go forward with
6.4 Risk assessment
implementation, controls, either process or product, need to
Risk assessment is required when a new automated system be used to mitigate and ⁄ or eliminate the identified poten-
is to be implemented, changed, upgraded or its retirement tial risks. Mitigation generally involves creating work-
planned. It must be performed to identify critical control arounds, either with independent software or written SOPs
points, to determine the degree of testing required and to that prevent the end-user from replicating the risk identi-
define risk mitigation plans. This requires considerations of fied system process. Documentation of the entire process
the impact, probability and detectability of a potential haz- must be produced, approved and controlled.
ard or harm to a computerized system.
Risk assessment also looks at the critical control points
6.5 Validation plan
in the software and can identify those areas where, if there
is a failure or malfunction, harm to the patient, donor or A validation plan should be prepared after a decision is
business may occur. made to implement a new, or change an existing system. It
A risk assessment has an important place in the valida- is recommended that the validation plan be prepared as a
tion process as it can maximize testing resources through co-operative effort by subject matter experts. The level of
‘Better ⁄ Smarter’ testing. Since it is impossible to test every- risks is a major factor in determining the level of effort to
thing, it is best to identify the riskiest functionalities and be applied in testing and other verification and validation
spend proportionally more time and effort on validating tasks. If the validation process encompasses only one vali-
these processes. It provides a set of guidelines to ensure that dation study, the information normally contained in the
those modules with the highest degree of risk are focused validation plan may be included in the validation testing
on most heavily. Once defined, a risk assessment helps to protocol. The validation plan is a historical record that is
explain the impact of a software failure, be it either func- archived at the completion of the validation process. It may
tional or financial. be revised, under change control, during the life of the vali-
Many automated systems used in blood banking are con- dation process.
sidered configurable software packages. A typical feature of The validation plan will provide a description of the
these systems is that they permit each end-user to develop automated system, the validation activities, responsibilities,
procedures, how the validation is to be done and expected different validation tasks and testing that have to be per-
outcomes together with the acceptance requirements. formed for ensuring the quality of the use of an automated
User and supplier roles and responsibilities for the vali- system.
dation activities will be defined. The identity of authors,
reviewers and approvers of the deliverables are identified in Installation Qualification. IQ shows that the system has
the plan. Procedures for documenting, reporting, evaluat- been installed correctly. Once IQ has commenced the sys-
ing and resolving incidents and deviations discovered dur- tem and infrastructure should be under formal change con-
ing the validation process should be included as well as a trol. Support from the supplier is required during IQ testing.
mechanism for documenting and justifying exceptions to Important IQ considerations are:
these procedures and the validation plan. • hardware and software installation;
The completed validation plan must be reviewed and • installation conditions (wiring, utilities, UPS, etc.);
approved according to the facility’s quality system policies. • interface connections;
The validation protocols will be used to produce docu- • calibration, preventative maintenance;
mented evidence that the system performs as intended. • safety features;
• supplier documentation, prints, drawings and manuals;
6.5.1 Validation approach and content of the valida- • software and hardware documentation;
tion plan • spare parts list;
The validation approach should cover the following topics • software backup;
that are included in the validation plan. • security aspects;
• environmental conditions (such as temperature, humid-
Scope of the validation. The scope of validation should ity).
specify the automated system’s identification, the context
of use of the automated system, the automated system’s Operational Qualification. In this phase, the automated
definition, the automated system’s boundaries, i.e what is system and process operating parameters should be chal-
in and out of scope for this validation project, the processes lenged to ensure that they will result in a product that
to be employed, and the the aim of the validation. meets all defined user requirements under all anticipated
conditions of manufacturing, including worst case testing.
Quality risk management. Quality risk management OQ considerations include:
should involve an initial risk assessment including a deci- • functionality of the automated system;
sion on whether the system or its part(s) is GxP regulated or • alarms and limits;
not. • configuration;
• process control limits monitored by the automated sys-
Validation strategy. The strategy to follow for validation tem;
will depend on the type and complexity of the automated • software operational parameters (ideally linked to the
system and the degree of risks of its use. It is mainly based functional and design specifications as provided by sup-
on the different elements identified in the risk assessment plier);
and documents provided by the supplier concerning the • automated system operational specifications;
supplier testing performed, use and the administration of • process operating procedures;
the concerned automated system. The amount, type and • process change control;
results of supplier testing may be used to focus and decide • training;
the amount of testing needed during the validation efforts. • preventive maintenance and calibration and monitor-
Validation strategy should define which activities may ing;
be performed prospectively, retrospectively or concurrently • data to prove stability and capability of the process
(see Section 13, Glossary for definitions).The strategy must where the automated system is used;
define the system platform(s) and controlled environment • evaluations for potential failure modes and worst-case
upon which the qualification processes are to be performed. conditions (risk analysis and critical control points, fail-
Qualification of complex blood management systems ure mode and effect analysis, fault tree analysis);
would ideally take place upon a frozen test system which is • backup and recovery;
identical to and separate from the live environment. Less • system access and security.
complicated equipment should be isolated from the opera-
tional environment during the validation testing. Performance Qualification. The objective is to demon-
Installation Qualification (IQ), Operational Qualification strate that the computerized process will consistently
(OQ), and Performance Qualification (PQ), classify the produce acceptable product ⁄ output under normal
operating conditions. Due to practical reasons part of • define the time when the automated system should be in
the limiting and boundary conditions testing is often operation.
performed at this stage. The demonstration is achieved
by using the appropriate methods and tools for process Validation deliverables. Relevant documents that must
validation. be obtained during the testing process should be specified
PQ considerations include: (screen prints, installation reports, SOPs that have to be
• use of actual computerized parameters and procedures produced, graphical displays, electronic data, etc.). These
established in OQ and used during the operation; documents will be used to evaluate whether the automated
• reconfirm acceptability of the computerized processes as system can or cannot be released.
established in OQ;
• reconfirm process repeatability and assure process sta-
Acceptance criteria. The general acceptance criteria for
bility when used in the field with trained operators;
validation testing and the acceptable overall outcome of
• data migration to the new platform.
the validation process should be defined in the validation
Challenges to the process should simulate conditions that
plan.
will be encountered during the operation. Challenges
should include the ranges of conditions covered by the
6.5.2 Validation protocols
SOPs and should be repeated enough times to assure that
Valdation testing is often performed using detailed valida-
the results are meaningful and consistent. Challenges will
tion protocols which are developed as required from the
need to include forcing the process to operate at its allowed
validation plan and the risk assessment. For IQ, OQ and PQ,
upper and lower limits.
validation protocols should contain:
Reports of qualification activities should be written
• the scope covered;
and the adherence to the requirements documented.
• the test instructions;
The qualified infrastructure should be under change
• the expected results;
control.
• the acceptance ⁄ rejection criteria;
• spaces for capturing results of the tests, including a pass
Supplementary Qualification(s). For more complex
or fail statement that confirms the outcome of the test,
systems it is often necessary to expand the qualification
and
exercise to include functionally specific testing which does
• a section for the tester and the reviewer to sign and date.
not readily conform to the criteria for IQ ⁄ OQ ⁄ PQ defined
Validation protocols should be independently reviewed
above. For example a separate Interface Qualification may
upon completion.
be required when validating interconnected systems or a
Cutover Qualification may be required to verify system
security or operational features following installation of 6.6 Data migration
the system in the live environment.
Data migration is the process of transferring existing data,
Formation of the validation team. The use of a team either manually or electronically, from a source system to
ensures that the validation processes are well analysed, that a target system (usually from an old system to a new
the protocols are comprehensive and that the final valida- system). The source as well as the target can be a single or
tion package is well documented and easy to follow. The multiple system. Data migration may vary in scope,
team should advise about ‘worst case’ scenarios, communi- complexity and risk, and should not be underestimated.
cate with key functional areas about new and changed The data migration process should be managed according
products and foster cross-functional cooperation. Members to a specific plan and requirements described in a data
of the validation team include: end users, quality assur- migration plan.
ance, IT and others (facilities engineering, manufacturing, The content of the data migration plan may vary
laboratory, technical services, research and development, depending on the complexity of the data migration pro-
regulatory affairs, purchasing, and top management) cesses. It must set forward sufficient elements to guide the
depending on the subject. data conversion team to a successful data migration. The
plan should cover but not be limited to: migration scope;
Timeline. Depending on the complexity of the validation roles and responsibilities; requirements and deliverables;
process, a timeline should be established in order to: risk analysis; configuration management strategy; software
• evaluate the time and resources spent on the validation; tools and strategies for ensuring compliance and fitness for
• define the timeline over which the validation should be intended use; data quality assessment; data mapping; data
performed; transformation rules; migration steps; data verification
strategy and acceptance criteria; system transition plan; and requirements. The migration may involve many phases
and rollback strategy. but it minimally includes data extraction where data is read
from the old system and data loading where data is written
6.6.1 Plan to the new system. Iterations are part of the execution of
In the planning stage, the first step is to perform a general the migration process. Prior to any iteration, parameters,
assessment of the requirements. Based on a risk assessment translation tables and code should be frozen to provide a
approach it is essential to identify and develop key ele- stable platform for the iteration.
ments of a data migration plan. Although data migration Each iteration of the process should at least include these
may vary in complexity, the objective is that data is usable control check points:
and that its context value remains. • collation of migration process timings (extraction,
For a successful migration, it is of vital importance that transmission, transformation and load);
there is a good understanding of the data which exists in • continual identification of data cleanse issues;
the current system. All possible data sources for the migra- • confirmation of parameter settings and parameter trans-
tion should be identified, and extractions and queries lations;
should be used to assess the ‘cleanliness’ of the data. Where • identification of any migration merge issues;
applicable, documented decisions should be made to • reconciliation;
cleanse the data. • deviations.
User requirements are formulated for the desired func- The execution of a data migration process should be con-
tionality of the data on the target system. If the target sys- sistently repeatable and accurate. The data migration pro-
tem is already in use in the production environment, care cess should be repeated until it reaches consistent results
should be taken to ensure that there is no discrepancy and meets the requirements set in the data migration plan.
between the user requirements and the existing functional- Once the migration test runs are completed and the data is
ity. accurately translated and completed, the integral end to
A migration specification document must be created end data migration process, as described in the data migra-
describing the mapping of the fields from the old system to tion plan, can be performed in the production environment.
the new system. The document should also contain all nec-
essary translations and ⁄ or modifications of database fields 6.6.3 Perform migration verification
during the migration process. After loading into the new system, results are subjected to
All migration steps as well as actions between the extrac- data verification to determine whether data was accurately
tion and the import must be documented in the data migra- translated, is complete, and supports processes in the new
tion plan. If it is necessary to perform additional actions on system. During verification, there may be a need to run
the target system (i.e. on the imported data or on the system both systems in parallel to identify areas of disparity and
as such), these actions should also be included in the docu- prevent erroneous or lost data.
ment. Data migration requires several steps and should Points for consideration are:
include verification of the data to ensure that the data being • is all user data correctly converted to the new format?
migrated is correct and in the proper format for use in the • are there any missing records or fields?
target system. There may be considerable differences • are new fields initialized to correct values?
between the database structure of the source system and One of the methods for testing and verifying results is
the target system. The format and the functional usage of sampling. In addition, there are manual inspections which
data in the receiving system can be significantly different; examine the results of a migration, and process checking,
for example, limitations in the field length can create which, unlike sampling and inspections, focuses on verify-
severe data integrity errors. ing that the tool or script used to move the data works as
Once the data is transferred it must be verified. Execution intended.
trials should be performed several times until they meet the The migration plan is executed and the process and
success criteria that have been set. migrated data validated. Ideally, validation should be per-
formed on the production system. In some cases this is not
6.6.2 Execute and report a possibility. This situation can arise when the production
Once the data migration plan is written and approved, system is in use, or because validation requires manipula-
migration test runs should be performed in a test environ- tion of the imported data that cannot be reversed. It may
ment. To achieve an effective data migration procedure, then be necessary to perform the validation on a copy of
data on the old system is mapped to the new system provid- the production system. In this case, the validation report
ing a design for data extraction and data loading. The should contain a precise description of the differences
design relates old data formats to the new system formats between the validation and the production environments,
and the impact the differences may have on the validation • specify the actual configuration and setup of the equip-
result. ment, operating system and utilities that make up the
When validation has been performed on a copied system, host machine.
the actual migration can subsequently be performed with (c) Installation Qualification should:
minimal testing on the production system. • capture the installation of the host, if serial number and
It is important after successful data migration that the model were defined they should be included, any addi-
access to data in the old system is locked to prevent the use tional components not installed by the manufacturer
of redundant ⁄ incorrect data. should be documented;
• include the operating system, patches and upgrades,
additional utilities and toolkits.
6.7 Infrastructure qualification
(d) Operational Qualification should:
A prerequisite to ensure a controlled and validated auto- • include at a minimum: backup and recovery, data archi-
mated system is a qualified infrastructure including serv- val and retrieval, security, system instruction manual
ers, networks and clients and other devices that are part verification, start-up and shutdown, uninterruptible
of the network. This provides the foundation upon which power supply, communication loss and recovery, any
the automated system, i.e., GxP application runs in an system redundancy such as mirrored drives, secondary
environment which is continuously maintained and in systems failover systems, etc.
control.
Normally the infrastructure is qualified with an IQ and 6.7.2 Network infrastructure
sometimes OQ. The PQ of the infrastructure is per se per- The network infrastructure can be defined as the transpor-
formed during the validation performed on every applica- tation and communication systems. Testing of the WAN
tion for its intended use. and LAN should be limited to the major components of the
The infrastructure can be divided into parts as follows: WAN ⁄ LAN. The network infrastructure is a dynamic envi-
• servers and hosts including operating systems and ronment, therefore, it is necessary to establish and follow
database engines; good engineering, documentation and quality assurance
• internal network infrastructure; switches, routers, cabling practices. Network upgrades require updated documenta-
and network monitoring tools, scheduling tools etc. tion and possible retesting.
within the organization; (a) Requirements Specification (URS ⁄ FS) should:
• user interfaces (clients); workstations, laptops including • specify the functional requirements for the major
web access tools etc; components of the WAN ⁄ LAN infrastructure;
• external interfaces, networks and security components. • specify the required redundancy of the infrastruc-
According to GAMP5, recording version numbers ture.
and verification of correct installations are sufficient (b) Design Specification should:
for qualifying infrastructure software which is composed • specify the actual equipment for the major parts of
of established and commercially available layered the WAN ⁄ LAN infrastructure. It is a description of the
infrastructure software (upon which the automated physical hardware components, such as hubs,
system application is built). The documentation and tests switches, routers, patch panels, and of the software
described below can be included in the validation of components such as transport protocols, network
the application. At least minimal testing is needed for operating systems. WAN ⁄ LAN interfaces are inclu-
infrastructure qualification since proving the application ded; other components such as cabling, power sup-
runs correctly using the established infrastructure is plies, interface cards should also be captured.
what is important. A risk-based assessment approach (c) Installation Qualification should:
should be used. • capture the physical installation of the major compo-
nents; if serial number and model were defined it they
6.7.1 Servers and hosts should be included;
The deliverables for servers and hosts should be limited to • include the documentation of software on standalone
the equipment and its associated operating system, and switches and routers.
utilities. System upgrades require updated documentation (d) Operational Qualification should:
and possible retesting. • Use automated test equipment to verify that the
(a) Requirements Specification (URS ⁄ FS) should: appropriate security levels and filters are operating
• specify the functional requirements for the host machine correctly, and that the cabling works according to the
and its operating system and utilities. requirements. Testing of networks will need to be a
(b) Design Specification should: team effort since many applications are part of the
network and integration with each other is very Once the documentation is established and the auto-
important. mated system installed, training can be performed with or
(e) Performance Qualification: without instructors, but supported with clear training
• A separate PQ is not expected for infrastructure as instructions and concurrent documentation. The compe-
the PQ of the infrastructure is per se included in the tency of the trained staff should be evaluated and docu-
OQ and PQ of the application(s) using the infrastruc- mented. Operators should be able to perform the intended
ture. functions and respond in an appropriate and timely manner
to all alarms, warnings and error messages.
6.7.3 Clients
Where the Administrator access rights to the clients can-
6.9 Testing
not be disabled for users they remain under the direct
control of the users themselves. It is typically difficult to Prior to testing, the system must be configured and frozen
demonstrate a state of control in the workstation environ- and a change control mechanism must be established. All
ment. It is possible to initially qualify and document the documents required for the qualification phase as defined
workstation, however, it produces a challenge to maintain in the validation plan must be available.
the controlled state. The clients should be controlled via The results from testing should be documented on the
policies, procedures, CD-images, and audits. System validation protocol or an annex document against prede-
upgrades require updated documentation and possible fined acceptance criteria stated in the test instructions. Test
retesting. anomalies should be captured and reviewed with the out-
(a) User Requirements Specification should: come documented (see Section 6.11, Problem resolution).
• specify the functional requirements for the type of The following rules for testing must be applied:
client workstations and laptops; • all test results should be recorded indelibly;
• document the organization’s standard type of clients • any corrections should be crossed out with a single line,
and the minimum hardware requirements as well as initialled and dated – a reason for the change should be
the current operating system, including patches, specified if not obvious to an auditor of the information;
upgrades and software to be used. • shorthand notations such as ticks should be avoided;
(b) Installation Qualification should: • test results should be documented directly as testing
• record system information in accordance with estab- occurs and should be retained – this includes screen
lished procedures, e.g. using a form. When a client is prints, reports, queries, etc.;
installed or modified a qualified individual should • problem logs and resolution should be maintained;
perform the tasks and complete the form. • testing summaries should be established.
(c) Operational Qualification should: Test results should be reviewed and approved by a com-
• for applications running on the clients, test and doc- petent independent person.
ument that the application operates according its
intended use in the client ⁄ server environment.
6.10 Business continuity plan
(d) Performance Qualification:
• a separate PQ is not expected for clients as the PQ of A business continuity plan is required and consists of a
the clients is per se included in the OQ and PQ of the number of elements designed to minimize disruption to the
application(s) running on the clients. business in case of system failure ⁄ unavailability. An
approach based on risk assessment is recommended.
• A countermeasure plan is a preventive plan that should
6.8 Training
be prepared to reduce the risk of system failure. This can
All personnel developing, maintaining or participating in include hardware redundancy, maintenance, system
the qualification process must be trained before begining monitoring and data backup procedures, training and
any validation activity in accordance with the facility security arrangements.
training policies. • A disaster recovery plan should be prepared detailing
A plan must be developed to ensure staff are trained on how the system will be recovered and brought back
the various functions they will be performing and that they into operation and staff must be trained on a regular
are declared to be competent. It should be specified who basis.
requires training, at which level they have to be trained and • Continuity action plans should identify those critical
the documents the training is based on. The choice of the activities that must be maintained during the period of
appropriate training methods will be determined based on system unavailability and document alternative
supplier support and system complexity. processes to be followed during this period.
The elements of the business continuity plan should • training requirements have been met;
be tested during validation and be subject to periodic • a business continuity plan is in place.
review and re-testing to verify their effectiveness. Top The possible outcomes from this review are:
management has to be informed about the impact of • release;
this plan. • conditional release;
• do not release.
The system can only be released by qualified person-
6.11 Problem resolution
nel. If the system cannot be released or can only be
All problems encountered during testing should be docu- conditionally released, the reason for the decision must
mented. Problems will fall into two categories: validation be documented. In all instances, the decisions made
test case failures and issues not related to testing. must focus upon the importance of patient and product
safety.
Validation failures. The following tasks have to be per- After release, the facility is responsible for maintaining
formed: the validated state of the automated system according to
• document all incidences of test case failure; pre-established plans.
• investigate all incidents to determine:
- if the test case was properly written;
6.13 Handover (go-live) process
- if there was user error in executing the test case;
- if there was a specification error; Transfer of responsibility of an automated system from pro-
- if there is a system limitation; ject to operation is needed once the system is ready to
• document findings and resolution; go-live. The handover process scope, period, acceptance
• depending on the change required to fix the problem, criteria and plan (checklist) should be established before-
determine if only the test case should be re-executed or if hand. The handover activities performed should be
regression testing of several functions is required. described and approved paying special attention to the
transfer of open issues and incomplete activities or docu-
Issues. Issues or problems that arise should be docu- mentation. A period of monitoring the system after go-live
mented, investigated and resolved before going live with a may be needed and a rollback strategy defined for serious
system. They are encountered when system limitations exist problems emerging. The formal acceptance of the auto-
because of such things as environment and resource con- mated system and controlled transfer into the live opera-
straints. Documenting the solution will provide historic tional environment should be documented.
information that will be valuable when making future deci-
sions. Depending on how critical the solution is, a test case
6.14 Validation state maintenance
should be executed. A risk assessment based approach
should be used. Maintaining the validated state is one of the most difficult
activities of guaranteeing the regulatory compliance and
fitness of use of an automated system. The maintenance
6.12 Validation report and final review
phase spans the time between the automated system’s
The validation report presents the results of the validation start-up and the retirement of the system. The following
activities, including data migration, interpretation of the items, which are essential to maintaining the validated
results and the conclusions drawn. If unexpected results are state, may already be covered within the facility’s quality
obtained they should be summarized. The summary should system:
define what changes and ⁄ or ‘workarounds’ will be needed • calibration and monitoring;
to mitigate the risk. • preventive maintenance;
The final review is performed by staff identified in the • incident management;
validation plan, upon completion of the validation process • software patches ⁄ service packs installation;
and consists of reviewing all documents generated during • training and competency;
that process. The review should confirm that: • supplier re-qualification;
• the documentation is complete; • periodic review;
• the testing proves, with a high degree of assurance, that • performance monitoring;
the system will consistently meet its acceptance criteria; • system retirement.
• data migration is complete and accurate; Operational change control, document control and qual-
• any non-conformance was addressed through problem ity control procedures support the maintenance of the vali-
solving; dated state.
6.14.1 Calibration and monitoring Records should be maintained for all equipment and
In order for any system (not limited to automated systems) should contain:
to maintain the validated state, all measuring and test • item identification;
equipment required by the application should be identified • date of last maintenance;
and calibrated. • due date (or usage time or frequency) for maintenance;
(a) It is necessary to establish a mechanism for assuring the • the person who performed the maintenance;
adequacy of the calibration and monitoring programs • PPM history;
and ensuring that qualified personnel are available for • link to calibration and monitoring records if appropri-
its implementation. ate.
(b) A calibration and monitoring plan is used to define the
requirements for establishing and implementing a cali- 6.14.3 Software patches ⁄ service packs installation
bration program that includes frequency of monitoring. A patch is a piece of code added to software in order to fix
This will ensure that the measuring and test equipment a bug, especially as a temporary correction between two
required for any process remains calibrated within the releases. This can also include changing the user interface
manufacturer’s specifications or the tolerances required and improving usability and performance. Though meant
by the facility. The calibration and monitoring proce- to fix problems, a poorly designed patch can sometimes
dure must be traceable to a recognized international introduce more problems. For this reason, it is very impor-
standard. tant that the same change control procedures are followed
(c) Trending and analysis of calibration and monitoring as when an entire automated device is installed. What dif-
results should be a continuous process. fers between installing a new system and installing a patch
(d) Calibration and monitoring intervals should be deter- to a system is the scope of the validation necessary to main-
mined for each item of equipment. The intervals should tain a safe system. In order to determine the scope of the
be established with the intent of achieving and main- needed validation, an impact analysis should be performed
taining a desired level of accuracy and quality. which includes making the following assessment:
(e) The calibration status of all equipment that requires • what programming has been modified and is included in
calibration should be readily available. the patch ⁄ service pack?
The record of calibration and monitoring should contain: • will this change have an impact on processes that people
• item identification; perform?
• date of last calibration and monitoring; • what is the risk if this change does not work?
• due date (or usage time or frequency) for re-calibra- The answers to all of these questions help to determine
tion and re-monitoring; the need for IQ, OQ, and ⁄ or PQ.
• person who executed the calibration and monitor- If the patch causes changes to working practices and ⁄ or
ing; processes then training people for the new processes must
• calibration certificate number (where available); be done to ensure personnel perform the entire process
• identity of calibrators and standards used; competently. PQ and training ensure changes made are
• results of calibration and monitoring; understood by anyone impacted.
• calibration and monitoring history. When automated system vendors release a patch or ser-
(f) There should be a calibration procedure for each item vice pack it is expected that they inform customers about
type. what has been fixed or added to the software and what the
impact is on the system. Normally the vendor does this by
6.14.2 Preventative maintenance producing Release Notes, an Update Manual or Service
All critical equipment should have regular, planned main- Pack Notes that accompany the patch or service pack. Using
tenance to detect or prevent avoidable errors. This Planned this information, the end user should be able to answer the
Preventative Maintenance (PPM) should include routine questions raised above. If the vendor does not disclose the
day-to-day and periodic maintenance. PPM will ensure that changes made it is very important that documentation of
the equipment required for any process remains in its opti- the changes is provided in order to minimize the amount of
mum functional state. validation needed and maximize the knowledge of the end
(a) All equipment that requires PPM should be identified. user.
(b) Maintenance intervals should be determined for each
item of equipment. 6.14.4 Training and competency
(c) The maintenance status of all equipment that requires The ability of staff to use and support an automated system
PPM should be readily available. correctly should be maintained. The training program
should be reassessed for any critical change in environ- • the relevant results obtained from the review;
ment, process or to the automated system. • deviations or problems found;
The training program should be adapted for each signifi- • required remedial work;
cant staff reassignment or newly assigned task related to • the ratification of the continued acceptability for the
the automated system. system use.
Training records, including plans and protocols of the Identified actions should be prioritised and planned. A
training status, ensure that training needs are properly risk assessment based approach should be used.
identified, planned, delivered and documented for the
entire validation process. 6.14.7 Performance monitoring
To ensure the proper operation of an automated system
6.14.5 Suppliers re-qualification consisting of computers, networks and applications, a mon-
The ability for a supplier to maintain activities related to an itoring plan should be developed and implemented. The
automated system has to be re-qualified on a regular basis plan should take into account the criticality of the system
in order to anticipate weakness, to improve the partnership being monitored and outline monitoring, user notification
or eventually to manage the supplier and ⁄ or automation and problem solving mechanisms.
system changes. Critical system conditions should be monitored with
The frequency and the detail of the re-qualification pro- suitable monitoring tools at appropriate time intervals. The
cess depends on the level of risk from using the automated monitoring plan should state acceptable and unacceptable
system. Re-qualification should be planned for every sup- system parameters, the monitoring tool to be used and the
plier concerned. frequency of observation.
This process can be performed through an audit similar If an unusual event is observed, personnel should follow
to the one used for system selection. An internal procedure the standard response outlined in the monitoring plan. The
should be written to describe the level of auditing required standard response will likely involve notifying affected
for re-qualifying suppliers based on the purpose of the personnel and initiating a resolution to the problem.
audit. Depending on the severity of the problem and the criticality
Supplier’s re-qualification is not limited to the audit, but of the system, a back-up plan may need to be implemented
also concerns the follow-up of post-audit findings. to keep the system operating (see Section 6.10, Business
The decision to continue with a supplier will depend on continuity plan).
the criteria established by the blood bank and the level of
compliance to the regulatory requirements applicable in 6.14.8 System retirement
the country concerned. At the end of operation, the automated system should be
decommissioned. The following rules should be applied:
6.14.6 Periodic review • if the retirement of the automated system involves a
Periodic review aims to establish that the system and vali- replacement, it should be planned;
dation documentation remains complete, current and accu- • consideration should be given to archiving system soft-
rate. ware;
Periodic review should be planned and scheduled. It • the data should be archived such that it can be retrieved
should consider: and read, unless the data is migrated to a validated
• validation documents for the system; replacement system;
• documentation for using and supporting the system • an archive report should be generated describing the
(SOPs, operational plans, related records); archive approach and listing the documents, raw data
• GxP regulations; and electronic records archived;
• the incremental effect of changes; • it should be possible to retrieve the data independently
• system maintenance, calibration and monitoring, inci- of the original system;
dent logs; • the data should be retained as required by the regula-
• any prior audit reports; tions and company policy.
• change in environment, process or business require-
ments, legislation or accepted best practices;
7. Security
• personnel;
• supplier’s contract reviews (including problem handling, Security policies should be developed for defining the rules
downtime, third party policy, etc.). and guidance regarding use and access to critical informa-
A report of the review process should be prepared and tion. It could be performed through the Guidelines on Infor-
should include: mation Security from ISBT [6].
GAMP: Good Automated Manufacturing Practice application server, which performs the bulk of any
GCP: Good Clinical Practice required data processing.
GLP: Good Laboratory Practice Computer system: A functional unit, consisting of one or
GMP: Good Manufacturing Practice more computers, associated peripheral input and output
GxP: Good ‘x’ Practice, where ‘x’ represents: devices and associated software, that uses common stor-
• Clinical age for all or part of a program and also for all or part of
• Quality the data necessary for the execution of the program;
• Distribution executes user-written or user-designated programs; per-
• Laboratory forms user-designated data manipulation, including
• Manufacturing arithmetic operations and logic operations; and that can
IQ: Installation Qualification execute programs that modify themselves during their
OQ: Operational Qualification execution. A computer system may be a stand-alone
PPM: Planned Preventive Maintenance unit or may consist of several interconnected units.
PQ: Performance Qualification Computerised system: Includes hardware, software,
QA: Quality Assurance peripheral devices, personnel and documentation; e.g.
QMS: Quality Management System manuals and Standard Operating Procedures.
SOP: Standard Operating Procedure Engineering diagrams: Description of the way a device is
URS: User Requirement Specification built. It could be electrical wiring schema, technical
UPS: Uninterruptible Power Supply information, etc. Where information must be presented
by means of a signal flow chart or circuit diagram, such
visual aids shall be divided into discrete units, simplified
13. Glossary
and standardized.
Automated System: Term used to cover a broad range of Functional Specification (FS): Description of the product
systems, including automated manufacturing equip- to be supplied in terms of the functions it will perform
ment, control systems, automated laboratory systems, and the facilities required to meet the user requirements.
manufacturing execution systems and computers run- It covers mechanical, electrical layout, hardware and
ning laboratory or manufacturing database systems. The software elements. This kind of document is written in
automated system consists of the hardware, software such a way that both supplier and user understand it.
and network components, together with the controlled Hardware design specifications: Description of the archi-
functions and associated documentation. tecture and configuration of the hardware. It includes
Calibration: The set of operations, which establish, under controllers, PCs, instrumentation and interfaces.
specified conditions, the relationship between values Installation requirements: Description of the environment
indicated by a measuring instrument or measuring into which the automated system should be installed.
system, or values represented by a material measure Manuals ⁄ User guides: Documents describing the use of the
and the corresponding known values of a reference system and the maintenance tasks that have to be per-
standard. formed by the user. It is a description of the product in
Certificates of calibration: Document signed by qualified terms of the functions it may perform and the facilities
authorities that testifies that a system’s qualification, required to appropriately utilize the product.
calibration, validation or revalidation has been per- Purchasing documentation: Document ordering any sig-
formed appropriately and that the results are acceptable. nificant part of the automated system, including equip-
Client: An application or system that accesses a remote ser- ment, computer system or part of it and new
vice on another computer system, known as a server, by development. It may be used for tracking the purchasing
way of a network. The term was first applied to devices process.
that were not capable of running their own stand-alone Patches ⁄ Service Packs: Code added to software in order to
programs, but could interact with remote computers via fix a bug, especially as a temporary correction between
a network. These dumb terminals were clients of the two releases.
time-sharing mainframe computer. A fat client (also Process Owner: The person ultimately responsible for the
known as a thick client or rich client) is a client that per- business process or processes being managed.
forms the bulk of any data processing operations itself, Software design specifications: Description of logical and
and does not necessarily rely on the server. A thin client physical structures of the program, the standards to be
is a minimal sort of client. Thin clients use the resources used for file naming, label allocation and module nam-
of the host computer. A thin client’s job is generally just ing. It defines how the software implements the require-
to graphically display pictures provided by an ments based on the functional specification.
Standard Operating Procedure (SOP): Written and Validation Plan: Description of the validation activities,
approved description of essential steps, their sequence, responsibilities and procedures. It describes specifically
responsibilities and precautionary measures necessary to how the validation is to be done.
assure that operations can be accomplished routinely Validation protocol: Prospective experimental (testing)
and in a uniform manner. plan that when executed is intended to produce
Supplier audit report: Presentation of the results of the documented evidence that the system performs as
investigation of the adequacy of the supplier to assure intended.
the quality and the reliability of the supplied automated Validation report: Presentation of the results of validation
system. activities, interpretation of the results and the conclu-
User Requirements Specification (URS): Clear and precise sions drawn. If unexpected results are obtained during
definition of what the user wants the system to do. It validation testing, it defines what changes will need to
defines the functions to be carried out, the data on be made or what workarounds will be implemented to
which the system will operate and the operating envi- mitigate risk.
ronment. The URS defines also any non-functional Validation, concurrent: Validation conducted when there
requirements, constraints such as time and costs and is no possibility to complete a validation program before
what deliverables are to be supplied. The emphasis releasing a product or part of it. In this case, all valida-
should be on the required functions and not the method tion concerns should be documented prior to the release
of implementing those functions. of the product.
Validation Master Plan: Describes the areas of the com- Validation, prospective: Validation conducted prior to the
pany within which validation is to take place and pro- distribution of either a new product, or product made
vides an overview of the status of planning. It lists the under a revised manufacturing process, where the revi-
areas, systems and projects being managed, defines the sions may affect the product’s characteristics.
status of validation for each and gives a broad indica- Validation, retrospective: Validation of a process for a
tion of when validation is to be completed. It is a general product already in distribution based upon accumu-
plan and would normally cover all production areas lated production, testing and control data. Test data is
and ⁄ or processes. It should include all systems for which useful only if methods and results are adequately
validation is planned. specific.
Appendix 1: Documentation
Documentation is an important element of the validation process. The following documents are typically required to provide
an audit trail and assure the quality of the validation process including the maintenance of the validation state.
SOPs Supplied by
Custom applications are developed to meet specific needs of Some automated systems are classified under more than one category
the user company. It may be a complete system or since they may have different configurations.