planning of erp sage x3 validation activities on ... - ulisboa
TRANSCRIPT
Planning of ERP SAGE X3 Validation activities on a risk-based
approach for a new pharmaceutical plant
Diogo António Camoesas Ramos
Thesis to obtain the Master of Science degree in
Master in Pharmaceutical Engineering
Supervisor(s): Prof. Dr. José Monteiro Cardoso de Menezes
MSc. Mara Diana Saavedra Cardoso Doria
Examination Committee
Chairperson: Prof. Dr. Pedro Paulo De Lacerda e Oliveira Santos
Supervisor: MSc. Mara Diana Saavedra Cardoso Doria
Member of the Committee: Prof. Dr. Rui Miguel Dias Loureiro
December 2019
I
Preface
The work presented in this thesis was developed at the company Labatec Farmacêutica S.A. (Sintra, Portugal),
during the period March to September 2019, under the supervision of MSc. Mara Doria. The thesis was co-
supervised by Prof. Dr. José Cardoso Menezes.
I declare that this document is an original work of my own authorship and that it fulfills all the requirements
of the Code of Conduct and Good Practices of the Universidade de Lisboa.
II
Acknowledgements
First, I would like to thank my supervisor Prof. Dr. José Cardoso Menezes for the work accomplished during the
pharmaceutical engineering master's degree and for the opportunity to develop this dissertation.
To Mara Doria, thank you for providing me with the opportunity to perform this thesis in Labatec Farmacêutica
S.A, for the support, availability and guidance during this Project.
To Marcella Santi, thank you for all the support, availability and patience, guidance and teaching provided
throughout this project.
To all Labatec Farmacêutica S.A team, thank you for welcoming me, for always being there to support and for
trusting me to contribute to the Labatec project.
Moreover, Thanks to all my friends who cared about me and helped me during the development of this
dissertation, especially to Raquel Saborano, Vasco Batista, Flávia Magalhães and Daniel Tavares.
A special thanks to my girlfriend Inês Correia, who contributed to everything, with availability, support,
guidance and friendship during all stages of this phase. This effort and dedication were very helpful to me.
Finally, I would like to thank my parents and brother for being the reason why I am finishing this phase of my
life, thank you for all your support, for trusting me and for always giving me the opportunity to continue to
develop this path to a successful future.
I dedicate this dissertation to my grandmothers, Adília and Fernanda, who are extraordinary women and who
take care of their families very well, as they have always done. It was the values you instilled in your children and
grandchildren that made them who they are, I am very proud. Thank you for everything.
“Trust, but verify” - Ronald Reagan
III
Abstract
The overall objective of this dissertation is to support the validation phase of a computerised system in the
pharmaceutical industry in order to ensure that the system will always function as expected without
compromising the quality of the product.
This dissertation aims to provide a guide on how to plan the validation activities of a computerised system,
highlighting its importance in an extremely regulated environment such as the pharmaceutical industry. The
computerised system referred in this work consists of the Enterprise Resource Planning SAGE X3 that manages
various activities of a pharmaceutical company, from the purchase of raw materials to the distribution of
products.
This dissertation presents a risk-based methodology that categorizes the risks of the different functionalities
of the system, establishing a framework for the planning of the qualification activities in order to provide a guide
for future implementation of computerised systems in the pharmaceutical industry. The application of this
methodology in the practical case of an Enterprise Resource Planning system for Labatec Farmacêutica S.A.,
allows to determine the impact of the system, to define the user requirements and to evaluate the functionalities
through a risk management tool (Failure Mode Effects Analysis). This resulted in a detailed sequence of tests and
actions to be performed in the appropriate qualification phases.
In conclusion, this thesis allowed to develop a risk-based validation plan to be applied in the validation of a
computerised system in a pharmaceutical company.
Keywords:
Computerised System Validation, Enterprise Resource Planning, User Requirements Specification, Risk-Based
Approach, Failure Mode Effects Analysis, Functional Risk Assessment
IV
Resumo
O objetivo geral desta dissertação é apoiar a fase de validação de um sistema computorizado na indústria
farmacêutica de forma a garantir que o sistema irá funcionar sempre como esperado sem comprometer a
qualidade do produto.
Esta dissertação tem como objetivo fornecer um guia sobre como planear as atividades de validação de um
sistema computorizado, realçando a sua importância num ambiente extremamente regulamentado como é o da
indústria farmacêutica. O sistema computorizado referido no âmbito desta dissertação consiste no sistema de
planeamento de recursos empresariais SAGE X3 que gere várias atividades de uma empresa farmacêutica, desde
a compra de matérias-primas à distribuição dos produtos.
Esta dissertação apresenta uma metodologia baseada no risco que categoriza os riscos das diferentes
funcionalidades do sistema, permitindo o planeamento estruturado das atividades de qualificação a fim de
fornecer um guia para futuras implementações de sistemas computorizados na indústria farmacêutica. A
aplicação desta metodologia no caso prático de um sistema de planeamento de recursos empresariais para a
Labatec Farmacêutica S.A., permite determinar o impacto GxP, definir os requisitos do utilizador e avaliar
funcionalidades através de uma ferramenta de gestão de risco (Failure Mode Effects Analysis). Isso resultou numa
sequência detalhada de testes e ações a serem realizados nas fases de qualificação apropriadas.
Em conclusão, esta tese permitiu desenvolver um plano de validação baseado no risco a aplicar na validação
de um sistema computorizado numa empresa farmacêutica.
Palavras-Chave:
Validação de Sistemas Computorizados, Planeamento de Recursos Empresariais, Especificação de Requisitos
de Utilizador, Abordagem baseada no risco, Análise de modo e efeito da falha, Avaliação de riscos funcionais.
V
Index
Preface ................................................................................................................................................................. I
Acknowledgements ............................................................................................................................................ II
Abstract .............................................................................................................................................................. III
Resumo .............................................................................................................................................................. IV
List of Figures ..................................................................................................................................................... VI
List of Tables ..................................................................................................................................................... VII
List of Abbreviations ........................................................................................................................................ VIII
1. Introduction .................................................................................................................................................. 1
Labatec Group .......................................................................................................................................... 1
Objective ................................................................................................................................................... 2
Computerised System............................................................................................................................... 2
1.3.1 Enterprise Resource Planning........................................................................................................... 3
1.3.2 ERPs in the Pharmaceutical Industry ................................................................................................ 4
1.3.3 SAGE X3............................................................................................................................................. 5
Computerised System Validation ............................................................................................................. 6
1.4.1 Regulatory Considerations ............................................................................................................... 6
1.4.2 Regulatory Requirements ............................................................................................................... 10
1.4.3 Good Automated Manufacturing Practices (GAMP®5) .................................................................. 13
1.4.4 Qualification Activities .................................................................................................................... 15
1.4.5 System Testing ................................................................................................................................ 16
Quality Risk Management ...................................................................................................................... 18
2. Methodology followed in the dissertation ................................................................................................. 21
3. Case Study: Planning of the ERP System Validation in Labatec Farmacêutica S.A. ................................... 22
ERP in Labatec Farmacêutica S.A. ........................................................................................................... 22
System Impact Assessment .................................................................................................................... 23
Validation Plan ........................................................................................................................................ 25
Development of the User Requirement Specifications .......................................................................... 27
Functional Risk Assessment .................................................................................................................... 39
4. Conclusions and Future work ..................................................................................................................... 56
5. Bibliography ................................................................................................................................................ 57
6. Annexes ...................................................................................................................................................... 61
VI
List of Figures
Figure 1 – Labatec logo ....................................................................................................................................... 1
Figure 2 - Labatec geographic expansion ........................................................................................................... 1
Figure 3 – Structure of a Computerised System in his Operating Environment ................................................ 2
Figure 4 – Evolution of the Enterprise Resource Planning Systems ................................................................... 4
Figure 5 – ERP modules....................................................................................................................................... 5
Figure 6 – Relationship between areas in a general pharmaceutical company ................................................. 5
Figure 7 – SAGE X3 Logo ..................................................................................................................................... 6
Figure 8 – ALCOA+ principles .............................................................................................................................. 9
Figure 9 – Gamp®5 Software Categories .......................................................................................................... 14
Figure 10 – V-Diagram for Validation of a Configured Product (Category 4) ................................................... 15
Figure 11 – Overview of a typical Quality Risk Management process ............................................................. 18
Figure 12 – Methodology of the dissertation ................................................................................................... 21
Figure 13 – Main ERP functionalities according to Labatec Farmacêutica SA processes ................................. 22
Figure 14 – Risk-based approach for CSV ......................................................................................................... 25
Figure 15 – Risk Class Assessment .................................................................................................................... 40
Figure 16 – Risk Priority Assessment ................................................................................................................ 41
VII
List of Tables
Table 1 – Regulations & Guidelines .................................................................................................................... 7
Table 2 – 21 CFR Part 11 and Annex 11: Comparisons ..................................................................................... 10
Table 3 - Summary of WLs related to CSV / Data Integrity between 2016 to 2018 ......................................... 11
Table 4 – Example of FDA Observations (483s) ................................................................................................ 12
Table 5 – Specifications..................................................................................................................................... 15
Table 6 – Qualification Activities ...................................................................................................................... 16
Table 7 – Scope of Application for System Testing Phases............................................................................... 16
Table 8 – Risk Analysis Methodologies ............................................................................................................. 20
Table 9 – Impact Assessment Result................................................................................................................. 23
Table 10 – Roles and Responsabilities for the validation of ERP System ......................................................... 26
Table 11 – DO and DONT’s when writing URS .................................................................................................. 27
Table 12 – URS reference for type of requirement .......................................................................................... 28
Table 13 – General Requirements .................................................................................................................... 29
Table 14 – URS for user Interface ..................................................................................................................... 29
Table 15 – URS for operation ............................................................................................................................ 30
Table 16 – URS for Access Control, Security & Safety ...................................................................................... 35
Table 17 – URS for data acquisition and recording .......................................................................................... 36
Table 18 – URS for Interfaces ........................................................................................................................... 37
Table 19 – URS for documentation and training .............................................................................................. 37
Table 20 – URS for maintenance ...................................................................................................................... 38
Table 21 – Risk Control Strategy ....................................................................................................................... 41
Table 22 – Risk Analysis Matrix ......................................................................................................................... 43
Table a-1 – Recommended Tests ...................................................................................................................... 61
Table a-2 – Example of FMEA template for FRA ............................................................................................... 63
VIII
List of Abbreviations
API – Active Pharmaceutical Ingredient
BOM – Bill of Materials
cGxP – Current Good Practices
CoA – Certificate of Analysis
COTS – Commercially off-the-shelf
CS – Computerised System
CSV - Computerised System Validation
DQ – Design Qualification
ERP – Enterprise Resource Planning
FDA – Food and Drug Administration
FEFO - First Expire, First Out
FIFO - First In, First Out
FMEA – Failure Mode Effects Analysis
FRA – Functional Risk Assessment
GDocP – Good Documentation Practices
GMP – Good Manufacturing Practices
GxP – Good Practices (where “x” stands for
Laboratory, Manufacturing, Documentation,
Distribution, etc.)
ICH – International Conference on
Harmonisation
IQ – Installation Qualification
MRP – Material Resource Planning
NEG – Distribution Product
OQ – Operational Qualification
PFI – Finished Product
PIC/S - Pharmaceutical Inspection Co-operation
Scheme
PQ – Performance Qualification
PSV – Bulk Product
QRM – Quality Risk Management
SOP – Standard Operational Procedure
URS – User Requirements Specification
VP – Validation Plan
WHO – World Health Organization
WL – Warning Letter
1
1. Introduction
In order to survive in highly competitive business environments, pharmaceutical companies have to
continuously improve their manufacturing and, equally important, their business processes1. The evolution of
the markets and the need to reach the target public more quickly led to the development of global distribution
networks, product expansion, competitive sales conditions and the commitment of companies to meet the
individual needs of the customer. As a result, the improvement of business flexibility is fundamental for their
development and positioning in the market, as well as for the high level quality standards as a differential factor2.
Labatec Group
Figure 1 – Labatec logo3
Labatec (Figure 1) is a pharmaceutical group based in Geneva, Switzerland, founded in 1957, with over 50
years of experience in producing and distributing quality pharmaceutical products for the European and
emerging markets.
With the desire to increase production levels, Labatec group decided to proceed with an expansion project
leading to the implementation of the new pharmaceutical plant in Portugal (Labatec Farmacêutica S.A.) and thus
explore the possibility to increase its presence in the European market.
Currently, Labatec covers both the retail and hospital sectors and has a portfolio of approximately 65 products
with the ambition to continue to expand. Its portfolio consists on injectable and solid oral products with
application in multiple therapeutic areas, including anti-infectives, oncology, women’s health, between others.
The factory production consists of tablets and oral capsules3.
The geographical presence of Labatec in 2019 is shown in figure 2. Red represents its headquarters in Geneva,
Switzerland. In brown, are the offices for the Middle East and North Africa markets in Amman, Jordan and the
new pharmaceutical plant in Sintra, Portugal. The markets where Labatec’s medicines are present, including
Switzerland and Jordan, are represented in blue.
Figure 2 - Labatec geographic expansion3
2
Objective
The objective of this dissertation is the development of a validation plan (VP) for an Enterprise Resource
Planning (ERP) for Labatec Farmacêutica S.A.
With the implementation of Labatec Farmacêutica S.A. in Portugal, there was the need to implement a
resource management system that could support all production and business-related processes for the new plant
and continue to manage those of the existing plant in Switzerland.
Therefore, in this phase of implementation of the ERP system, the validation activities were initiated in order
to ensure the quality and compliance of the system with the regulatory requirements for pharmaceutical industry
and according to the expected use for the system.
In order to understand the concepts of ERP, the validation of computerised systems (CS) and their importance
in relation to the regulations present in the pharmaceutical industry, a literature search was conducted to
support the case study presented in this dissertation.
Computerised System
In order to contextualize the components of a CS, it is important to enhance the concepts of software and
hardware. A software is defined as an organized information in the form of operating systems, utilities, programs,
and applications that enable computers to work. The hardware consists of the physical components that
constitute a computer on which the software is hosted4.
A CS comprises all the components of a specific system, including the software and hardware on which it is
installed (i.e. the computer system), the associated equipment (if applicable) and all external influences that
interfere with the CS in its operating environment (i.e. users, training, standard operating procedure (SOP) and
quality management of the system)5. Figure 3 schematically shows the hierarchical structure of the CS and its
components.
Figure 3 – Structure of a Computerised System in his Operating Environment
Adapted from PIC/S5
3
1.3.1 Enterprise Resource Planning
In order to better understand the definition of an ERP system, it is necessary to start by defining and clarifying
two concepts: ERP software and ERP system. An ERP software is a commercially available packaged enterprise
computing software, that can be standard, configured or customized, with applicability in different areas such as
finance, supply chain, manufacturing management, quality, sales and marketing6.
An ERP system is a CS composed of an ERP software and all the necessary infrastructure for the software to
function properly: hardware, operating system, SOPs, users, database and network.
The main goal of an ERP system is to manage all the administrative and operational processes in order to
improve the organization, processes and flow of information within the company, leading to an increase of
productivity, quality and income6–8. Some benefits of its implementation are data organization, integration of
different areas and improvements in resource management6.
Evolution of ERP systems
The concept of a system that manages the business processes began to emerge in the 1960s, when the
priority of manufacturing companies was to manage their inventory using computerised technologies as a
solution to optimize the inventory management9,10.
In the 1970s, companies began to realize that maintaining large amounts of inventory represented a waste
of resources. This led to the introduction of material resource planning (MRP) systems, allowing companies to
use a master production schedule supported by a bill of materials (BOM) that identify the specific materials and
their quantities to perform a certain manufacturing operation. This allowed companies to start managing the
manufacturing process with manufacturing orders, creating a production priority mechanism that resulted in a
significant increase in productivity and process quality9,10.
Over the years, more features were included in the MRP systems, such as tools to manage sales and
production levels, forecasting, sales planning and customer-order. In the 1980s, companies began to take
advantage of the technology performance to incorporate financial accounting and management systems along
with the manufacturing and materials management systems. This incorporation enabled the integration of
different areas in the same business, resulting in the so-called MRP II9,10.
In the early 1990s, improvements were implemented which allowed MRP II to incorporate even more areas,
such as product design, warehouse management, materials planning, capacity planning, communication system,
human resources, and project management. Hence, the term ERP was introduced to enable this technology to
be used by any company that intends to increase its competitiveness and quality of processes6,9–11.
Currently, the evolution of technology continued to change ERP in terms of architecture and services. The
goal now is for each ERP company to offer the best customer service in terms of system operability and service
conditions. Figure 4 summarizes the described evolution of ERP systems over the years.
4
Figure 4 – Evolution of the Enterprise Resource Planning Systems
1.3.2 ERPs in the Pharmaceutical Industry
Nowadays, the pharmaceutical industry is facing numerous business challenges such as strict regulatory
demands, global competition, individualized products, product expanding, technological innovation, R&D
development and unpredictable market trends12. Consumers and producers are looking for healthcare products
with high quality at compelling prices, which propels pharma manufacturers and distributors to develop solutions
to reduce production cost and maximize organization and efficiency1,13–15.
The ERPs in the pharmaceutical industries have a wide applicability, supporting several processes and
allowing an effective management of the company's resources. These systems have several functionalities in the
form of modules that are implemented according to the needs of the user. The main activities that an ERP system
can address in a pharmaceutical industry are represented below9,16:
• Manufacturing: Trace the materials to be used in the process in a BOM, plan the manufacturing process,
product life cycle management and quality control;
• Inventory & Material Management: Control material wastage and monitoring inventory levels. This module
identifies material requirements for manufacturing process, creates triggers for procurement and replenishment
and formulates inventory status reports;
• Distribution management: Batch tracking module allows manufacturers to monitor a batch work-in-
process and delivery status remotely;
• Purchasing: Purchase of raw materials, placing orders with suppliers, billing and support for continuous and
integrated active processing of purchase orders and entry of goods receipts;
• Finance & Accounting: Analysis and reporting of financial transactions;
• Human Resources: This module organizes the payroll, the roster, recruiting and training;
• Customer Relationship Management: Customer and supplier service, sales and marketing.
• Sales & Marketing Management: This module enables contract management and sales order processing
instantly. It can be used to record customer records and history and to create automated marketing workflows.
InventoryControl 1960's
MRP 1970's
MRP II 1980's
ERP 1990's
ERP in Cloud (2000-2010s)
5
Figure 5 – ERP modules17
An ERP system in a manufacturing unit “works like the central nervous system in the human body”13 by
integrating several areas within a company as schematically represented in figure 6. This enables cooperation
between all departments, enhances transparency and improves the productivity of operations. These advantages
justify the increasing need for ERP systems in the pharmaceutical manufacturing industry.
Figure 6 – Relationship between areas in a general pharmaceutical company
Addapted from18
1.3.3 SAGE X3
SAGE X3 is the ERP implemented by Labatec Farmacêutica S.A. by strategic reasons, since this software is
already in use at Labatec Switzerland. SAGE X3 was developed by Adonix, an ERP software company founded by
Emile Hamou, in 1979 in Paris, France19. In 2005 the SAGE group acquired Adonix, including X3 in its portfolio.
Under Sage's ownership, the Sage X3 product (previously named Adonix X3) prospered with large investments in
user interface and other functionalities that enabled X3 to become the global ERP solution it is today19.
SAGE X3 is a standard, commercially available, configurable ERP software used to manage most of a
company's functions, for example purchasing, sales, production and quality. Is a highly recommended ERP with
multiple functionalities in different types of industries16,20.
Since the pharmaceutical industry is one of the most regulated industries, and the demand to validate the
CS, this option facilitates the process by offering features such as Audit Trail (i.e. a secure, computer generated,
chronologial record evidence of a sequence of activities that have affected at any time a specific operation),
6
Validation Scripts, Security Features (e.g.: automatic logoff after a period of inactivity, management of access
control), among others20.
Figure 7 – SAGE X3 Logo16
Computerised System Validation
Validation is the process of establishing documented evidence that an equipment/utility or system will
consistently produce a result that meets predetermined specifications and quality attributes21.
CSs shall be validated in accordance with the principles of quality risk management and the validation shall
be prepared in accordance with the potential impact for the quality, the complexity and the intended use5,22.
Thus, systems that are considered to have an impact in the good practices (GxP) must be validated23,24. The
extension of the validation is defined according to the risk associated with the system22. Validation allows a better
understanding of the system, to exploit its full capabilities and to ensure that all necessary technical and
procedural controls are implemented in compliance with the applicable good practices, guidelines and
regulations21.
1.4.1 Regulatory Considerations
Several entities, such as EudraLex, World Health Organization (WHO), Pharmaceutical Inspection Co-
operation Scheme (PIC/S), International Conference on Harmonisation (ICH) among others, have published
guidelines with the objective of harmonizing the concepts and providing guidance to the industries implementing
quality processes. In order to understand the regulatory and industrial guidance rationale for the risk-based
approach outlined for the Computerised System Validation (CSV) in this dissertation, some sections of these
documents are cited in table 1.
7
Table 1 – Regulations & Guidelines
Regulation or
Guideline Scope of the Document
EU GMP Annex 11:
Computerised
Systems25
This document applies to all CSs used as part of regulated Good Manufacturing Practices
(GMP) activities. It defines what a computer system is, recommends how risk
management, validation and the operational phase of the system should be done.
“A computer system is a set of software and hardware components which together fulfill
certain functionalities…The application should be validated”
“As part of a risk management system, decisions on the extent of validation and data
integrity controls should be based on a justified and documented risk assessment of the
computerised system”.
EU GMP Annex 15:
Qualification and
Validation21
This document describes the principles of qualification and validation. This annex refers
that “Computerised systems used for the manufacture of medicinal products should also
be validated according to the requirements of Annex 11”.
The definitions of User Requirements Specification (URS), Design Qualification (DQ),
Installation Qualification (IQ), Operational Qualification (OQ), Performance Qualification
(PQ)) are defined in this annex.
WHO Guidelines on
Validation:
Appendix 5 –
Validation of
Computerised
Systems24
This document presents guidelines for the validation of CS: “Computerized systems should
be validated in accordance with quality risk management principles and the level of
validation should be commensurate to identified risks, complexity and intended use. This
guide applies to systems used in GMP but may be extended to systems used in all good
practice activities, as appropriate.”
In this guideline different concepts related to computer systems are presented, and the
qualification phases are defined.
EU Directive
2003/94/EC (Good
Manufacturing
Practice)26
“When electronic, photographic or other data processing systems are used instead of
written documents, the manufacturer shall first validate the systems by showing that the
data will be appropriately stored during the anticipated period of storage. The
electronically stored data shall be protected, by methods such as duplication or back-up
and transfer on to another storage system, against loss or damage of data, and audit trails
shall be maintained.”
8
Regulation or
Guideline Scope of the Document
21 CFR Part 11 –
Electronic Records
& Electronic
Signatures – Scope
and Application27
The U.S Food and Drug Administration (FDA) in the validation section recommends:
“… that your decision to validate computerized systems, and the extent of the validation,
take into account the impact the systems have on your ability to meet predicate rule
requirements. You should also consider the impact those systems might have on the
accuracy, reliability, integrity, availability, and authenticity of required records and
signatures” In this section the FDA adopts the same risk-based approach as EU Annex 11
for the validation of computer systems: “… that you base your approach on a justified and
documented risk assessment and a determination of the potential of the system to affect
product quality and safety, and record integrity.“
21 CFR 820.70 –
Quality System
Regulation: Subpart
G - Production and
Process Controls28
(i) Automated Processes: "When computers or automated data processing systems are
used as part of production or the quality system, the manufacturer shall validate computer
software for its intended use according to an established protocol. All software changes
shall be validated before approval and issuance. These validation activities and results shall
be documented. “
ICH Q7 – Good
Manufacturing
Practice guide for
active
pharmaceutical
ingredients23
The ICH Q7 refers the CSs in section 5.4, stating that:
“GMP related computerized systems should be validated. The depth and scope of
validation depends on the diversity, complexity and criticality of the computerized
application.” “Appropriate installation qualification and operational qualification should
demonstrate the suitability of computer hardware and software to perform assigned
tasks.”
PIC/S – Good
Practices for
computerised
systems in
regulated “GxP”
environment5
This document provides recommendations and background information concerning
the implementation, operation and inspection of CS.
Section 4.3 refers that: “Commercial ‘off the shelf’, ‘standard’, or proprietary systems
can be particularly difficult to assess from a quality and performance point of view. For
GxP regulated applications it is essential for the regulated user to define a requirement
specification prior to selection and to carry out a properly documented supplier assessment
and risk analysis for the various system options.”
Section 5.2 refers that: “The business/GxP criticality and risks relating to the
application will determine the nature and extent of any assessment of suppliers and
software products.”
Section 23.7 defines that “GxP critical computerised systems are those that can affect
product quality and patient safety, either directly (e.g. control systems) or the integrity of
product related information (e.g. data/information systems relating to coding,
randomization, distribution, product recalls, clinical measures, patient records, donation
sources, laboratory data, etc.).”
9
Regulation or
Guideline Scope of the Document
GAMP®522
The GAMP®5 is a document that provides direction in applying different concepts in
the development, implementation, validation and maintenance of CS. This document
presents a risk-based approach to software categorization, criticality of the system, to
define system risks and a validation strategy accordingly.
This research aims to introduce the concepts of CSV, risk management and to highlight their importance in
the pharmaceutical industry. As can be verified in Table 1, regulations and guidelines focus on risk management
methodologies in CSV and how the extent of validation should take into account the criticality of the system (i.e.
GxP Impact). Compliance with the requirements imposed by regulatory agencies is extremely important, and the
knowledge and application of these guides enable to attain the requirements demanded by these entities.
Good Documentation Practices and Data Integrity
As a regulatory requirement for CS, it is essential that there is an effective control and management of
documentation as it is a critical part of every system that is supported by GxP data and is related to the creation
of records within the organization5,29.
If a company wants to be compliant with the requirements of regulatory entities, evidence that the Good
Documentation Practices (GDocP) are followed is key. Good documentation is an integral part of the quality
assurance system. Data can be present in different formats, such as in paper or electronic (e.g.: ERP)30.
Amongst the aspects regulated by GxP guidance, those related to data should be a priority for a company.
Data integrity is defined as all the proceedings that enable the maintenance of, and the assurance of the accuracy
and consistency of data from initial generation, use, retention, archiving, retrieval and destruction29. To comply
with the GDocP, it is required that the documentation follows the Data Integrity ALCOA+ principles29,31 (in Figure
8) to ensure reliability and integrity of information and data throughout all aspects of their lifecycle29,32.
Figure 8 – ALCOA+ principles
Adapted from 31
10
1.4.2 Regulatory Requirements
A risk-based approach is referenced in both FDA regulations 21 CFR Part 11 and EMA EU GMP guide Annex
11, as a useful resource for the current use of the CS as well as for its validation13.
Title 21, Part 11 of the FDA Code of Federal Regulations is a regulatory document for using electronic records
and electronic signatures. The code requires pharmaceutical companies, medicinal device manufacturers,
biotech companies and other FDA-regulated industries (except food manufacturers) to implement controls that
include audits, system validation and documentation33. This includes software and systems involved in
processing many forms of data as part of business operation and product development such as an ERP
system20,33.
EudraLex Annex 11 is a guideline that applies to all forms of CSs used as part of a GMP regulated activities.
This annex refers that when a CS replaces a manual operation, there must be no decrease in product quality,
process control or quality assurance, nor any increase in the risk in the process25.
For companies to be compliant with this annex they must perform an appropriate validation to guarantee the
quality of its processes, considering the significance of the CS to be implemented, as is related to any GxP
regulated activities (e.g., GxP data management or batch release)25.
The main difference between these two documents is that while the scope of FDA Part 11 details more on
digital signatures, electronic records and CS that employ these features for regulated activities, EudraLex Annex
11 scope applies to all forms of CS used as part of GxP regulated activities and focus on a risk-based quality
management of the CS34. Together, they provide a robust and applicable guide to CSV activities that lead to
compliant practices in regard to regulatory and customer requirements35. A general comparison between the
two guides is summarized in table 2.
Table 2 – 21 CFR Part 11 and Annex 11: Comparisons 34
Scope
FDA CFR Part 11 EudraLex Annex 11
Defines requirements for electronic records
and electronic signatures used in FDA
regulated industries.
CSs as part of GMP-regulated activities.
All CSs automating any regulated function,
creating, modifying, and maintaining electronic
records and managing electronic signatures
must be validated for its intended use.
Focus Using electronic records and signatures in
computer systems.
Risk-based quality management of
computerised systems.
Objective
Electronic records and signatures must be as
trustworthy and reliable as paper records
and handwritten signatures and be
permanently linked to their respective
records.
These should include the time and date of
the activity and the signature of the user.
Using a CS should ensure there is no decrease in
quality, process control and quality assurance
and there should be no increase in the overall
risk.
11
Warning Letters
FDA conducts inspections to regulated companies, and when FDA detects a failure during an inspection, an
observation in the form of warning letter (WL) is issued listing significant violations of current good practices
(cGxPs)36.
The observations made in the scope of an FDA inspection are referred to as 483s. "Inspection observations"
is a form used by the FDA to document and report non-conformities detected during inspections37.
This search of WLs38 is primarily intended to raise awareness of the importance of pharmaceutical companies
to comply with regulations and guidelines and to understand the position of regulators.
This section highlights some examples of WLs related to the validation and use of software and/or CS in the
pharmaceutical industry (Table 3), reinforcing the importance of the subject of this dissertation, issued between
2016 and 2018 and accessible in the FDA database39.
Table 3 - Summary of WLs related to CSV / Data Integrity between 2016 to 2018
2016 2017 2018
WLs 31 22 14
Mo
st f
req
uen
tly
no
n-c
on
form
itie
s co
mm
itte
d
by
ph
arm
aceu
tica
l in
du
stri
es
Failure to validate regulated software/system and/or have validation procedures.
10 (32%) 6 (27%) 3 (21%)
Failure to ensure data integrity (data security, data manipulation, deletion, back-dating, audit
trail, access levels, user management)
16 (52%) 14 (63%) 10 (72%)
Failure to control/use GxP related spreadsheets
2 (6%) 1 (5%) 1 (7%)
Failure to document the software version used
3 (10%) - -
Failure to follow change control process and document the adequacy of the tool used to transfer
software changes
- 1 (5%) -
12
Table 4 presents some examples of WLs issued to pharmaceutical companies.
Table 4 – Example of FDA Observations (483s)
Examples of FDA 483s (2016-2018)
Ipca Laboratories Limited 29/01/201640
“Failure to have computerised systems with sufficient controls to prevent unauthorized access or changes
to data. Your firm relied on incomplete records to evaluate the quality of your drugs and to determine whether
your drugs conformed with established specifications and standards” … “We found that laboratory analysts
had PC administrator access that they utilized to manipulate raw data and test results.”
“We found that controls on your computerized chromatographic instrumentation were not adequate to
prevent analysts from manipulating processing parameters in order to obtain passing results. We also found
that your computerised systems lacked controls to prevent the backdating of test data. In addition to these
examples of computerised systems that permitted inappropriate manipulation of integration parameters and
backdating, our investigators also found several instances of computerized data systems that failed to prevent
the deletion of original injections.”
Bedfont Scientific, 04/02/201641
“Failure to ensure that when computers or automated data processing systems are used as part of
production or the quality system, the manufacturer shall validate computer software for its intended use
according to an established protocol, as required by 21 CFR 820.70(i). For example, your firm has not validated
the software, (b)(4), used to manage various activities such as complaints, Corrective actions, Preventive
action, repairs, servicing, internal and external audits, and warranty service. Your firm has been utilizing this
software since January 2011.”
Polydrug Laboratories Pvt. Ltd. 14/04/201642
“Failure of computerised systems to have sufficient controls to prevent unauthorized access or changes to
data. Your firm’s computer system for entering test results and storing certificates of analysis (CoA), which
document whether a drug meets specifications, does not have sufficient controls to prevent unauthorized
changes to a CoA after quality unit approval. A manager demonstrated for our investigator how results on an
already finalized CoA could be manipulated after the formal quality unit approval. Also, the quality unit’s
electronic signatures on these CoA were uncontrolled images of signatures rather than certificate-based
electronic signatures.”
F.P. Rubinstein Y Cia SR 05/05/201643
“Failure to validate computer software for its intended use according to an established protocol, when
computers or automated data processing systems are used as part of production or the quality system, as
required by 21 CFR 820.70(i). For example, your firm has not validated the following software used in its quality
system: a. (b)(4), used for complaint handling; b. (b)(4), used for complaint handling by your firm's sales force;
and c. (b)(4), used for data analysis.”
13
Examples of FDA 483s (2016-2018)
USV Limited 10/03/201744
“Your firm failed to exercise appropriate controls over computer or related systems to assure that only
authorized personnel institute changes in master production and control records, or other records (21 CFR
211.68(b)). Your systems allowed operators to delete files. You had no procedure to control this practice or to
ensure a backup file was maintained. No restricted access to the microbial identification instrument. Further,
you lacked restricted access to the external hard drive used for backup of this instrument. All users could
delete or modify files.”
Dynavision International LLC 09/05/201745
“Failure to perform a risk analysis for the Dynavision D2 device, as required by 21 CFR 820.30.
Failure to establish and maintain adequate procedures for the identification, documentation, validation,
or where appropriate, verification, review, and approval of design changes before their implementation, as
required by 21 CFR 820.30(i). Specifically, the “VALIDATION AND CONTROL OF COMPUTER SOFTWARE”
procedure, #DYN-OP-VDC-01, dated 5/24/13, has not been implemented, and there is no validation for the
software revisions you have made to the Dynavision D2 since 2011.”
Becton Dickinson & Company 11/01/201846
“Failure to validate computer software for its intended use according to an established protocol when
computers or automated data processing systems are used as part of production or the quality system, as
required by 21 CFR 820.70(i). For example, during the inspection, your firm’s World Wide Vice President for
Quality Management explained that your firm has no written procedures for validating the use of (b)(4).”
1.4.3 Good Automated Manufacturing Practices (GAMP®5)
GAMP®5 “A Risk-Based Approach to Compliant GxP Computerised Systems”22 was published in 2008, and is a
guidance document which provides a framework for risk-based approach to CSV where the system and the extent
of the validation activities are defined according to the category of the software complexity. Categorizing the
software helps to guide the writing of the system documentation (including user requirements specification and
test scripts). Currently there are four categories (the second category has been discontinued in the new version
of GAMP®5).
Nature of the Software: GAMP®5 Software Categories22
• Category 1: Infrastructure Software
This category includes the Infrastructure software tools (batch job scheduling, anti-virus) and established or
commercially available layered software (operating systems, databases managers…).
• Category 3: Non-Configured Products
This category includes commercially off-the-shelf (COTS) products used for business purposes, including the
systems that cannot be configured and systems that can have a simple configuration, but for which only one type
of default configuration is used. In such cases, and based on risk and supplier assessment, a simple one-step
14
testing approach is normally applicable. Tests usually check the correct installation, if the software meets the
fulfills the requirements and any further test derived from risk assessment. Depending on the complexity and
risk of the configurable COTS software in the business, can be included in category 4.
• Category 4: Configured Products
This category includes configurated COTS products which provide standard interfaces and functions that
allow modulation of the software to fulfill user-specific business processes. This typically involves simple
configuration of predefined software modules (i.e. configuration or parameterization) or a complex configuration
of the application (i.e. modification of the application source-code). The approach should reflect the result of the
supplier assessment, GxP impact, intended use and complexity. Strategies should be defined for mitigating any
identified risks.
• Category 5: Custom Applications
This category includes systems or subsystems that are developed to meet specific needs. The risk of these
customizable software is high.
The product lifecycle approach and validation activities should take into account this increased risk, since the
system was developed from the start, there is no prior knowledge about the functionalities and possible risks of
the system. The approach should address the software layers involved and their respective categories. It should
reflect the supplier's assessment and any audit observations, GxP impact, intended use, size and complexity.
Strategies for mitigating any identified risk should be defined.
GAMP standards have developed five (currently four) software categories (Figure 9) based on the level of
software complexity.
Figure 9 – Gamp®5 Software Categories22
According to GAMP®5 categorization, ERP configured software fits in the category 4. Therefore, it will be in
this category that this work will be focused on.
GAMP®5 approach can be summed up by a V-model diagram (Figure 10) according to the respective
category22. The diagram (category 4) places in juxtaposition the specifications produced for a system to the
testing performed as part of the qualification process.
15
Figure 10 – V-Diagram for Validation of a Configured Product (Category 4)
Adapted from GAMP®522
The specifications produced for the system represent the configuration, including the settings and
parameters of the system, the functionalities and the requirements the users expect to be represented in the
system. The specifications and their definitions are represented in Table 5.
Table 5 – Specifications22
Specifications Description
Configuration
Specification
Configuration Specifications may cover the configuration of the software products
that comprise the system. This includes the definition of all settings and parameters.
These specifications are often developed by the supplier and reviewed, tested and
approved by the validation team of the user company.
Functional
Specification
Functional Specifications are usually developed by the supplier and describe the
detailed functions of the system, i.e. what and how the system will do to fulfill the
business requirements. The user company must review, test and approve the
Functional Specifications. These specifications are often referred to as a contract
document.
User Requirements
Specification
Requirement Specifications are developed by the user company and should cover
all the requirements the users expect to be represented in the system. These
requirements should be developed considering the intended use and the
compliance with the applicable regulations.
1.4.4 Qualification Activities
Qualification is described as the action of assuring that a certain equipment/utility or system works as
intended and lead to the expected results. The different qualification phases address the testing of a component
or function of the system to be validated against a specific outcome21,25.
Qualification activities should consider all stages from initial development of the user requirements
specification to the discontinuation of the system21,25. The main phases of the qualification process and their
definitions, according to Eudralex is represented in Table 6.
16
Table 6 – Qualification Activities
Qualification Description21,25
Design Qualification
Documented verification that all documented specifications suggested for the
system by the supplier are verified and compared with the URS, guaranteeing that
the system is suitable for the intended purpose.
Installation
Qualification
Documented verification that the system is installed according to pre-approved
specifications.
Operational
Qualification
Documented verification that the system operates according to pre-approved
specifications and within the specified operating ranges.
Performance
Qualification
Documented verification that the system is capable of performing the activities of
the processes it is intended to perform, according to pre-approved specifications,
within the scope of the business process and operating environment.
Requalification
Lifecycle overview of the system to ensure that qualification status is maintained. If
such a change has a significant impact, a requalification shall be performed to
confirm that the CS remains in a state of control.
1.4.5 System Testing
The pharmaceutical industrial policies and strict regulations require that systems are developed, documented
and tested following the different GxP’s47,48.
The software products, such as ERP software that are described within the scope of this dissertation, are
usually classified as GAMP Category 4 (products configured for a specific business process). For the ERP according
to the “GAMP Good Practice Guide: Testing GxP Systems” a testing approach based on configuration verification,
functionality and performance test is applicable (Table 7).
Table 7 – Scope of Application for System Testing Phases
Qualification
Phase Test Phase Scope of Application
Installation
Qualification
Configuration
Verification
Verification of configuration against the configuration specifications. These
tests are intended to verify the correct installation of49:
• Hardware and software installation (if applicable);
• Interface connections (e.g.: printers);
• Software backup functionality;
• Safety and Security features (e.g. Audit trail functionality);
• Access levels definitions (including profile levels and functions);
• Availability of Supplier documentation, prints, drawings and manuals;
• Availability of Software and hardware documentation.
17
Qualification
Phase Test Phase Scope of Application
Operational
Qualification
Functional
Test
Verification of functional elements and ensure that the system meets all user-
defined requirements under all approved conditions by conducting user
acceptance tests. These tests are intended to force the system into extreme
and stressful conditions and are aimed to check49:
• Invalid values and inputs;
• System functionalities;
• Error messages;
• Functional and data validity;
• Transactions validity;
• Availability of SOPs for maintenance, backup and restore, user
operation, system security…;
• Training in system operation (e.g.: training in applicable procedures).
Performance
Qualification
Performance
Test
This phase of testing is intended to demonstrate that the system will
consistently produce an acceptable output under normal operating
conditions. These tests should cover50:
• Use of actual computerised parameters and procedures established in
OQ and used during in operation;
• Reconfirm acceptability of the computerised processes as established in
OQ;
• Reconfirm process repeatability and assure process stability when used
in the field with trained operators;
• Data conversion and migration to the new platform;
• Simulate conditions that will be encountered during routine operation;
• Include the ranges of conditions covered by the SOPs;
• Repeat tests enough times to assure that the results are meaningful and
consistent;
*DQ also considered in GAMP®5 as Design Review phase consists of the revision of the specifications and
documentation associated with the development of the software design. As the ERP is a configured software,
this qualification phase does not apply once Design Review activities are usually performed by the developer
during the development of the product. This should be verified during supplier assessment. Design Reviews
typically are conducted for customized applications to a level of detail of specification, i.e for customizations that
involves changes to standard features such as the creation of software's programming code22.
The scope and extension of testing should be determined by a justified and documented risk assessment,
taking into account both the potential effect on good practices and the complexity of the system. These tests
should be considered when conducting the assessment of the system functionalities (i.e. Functional Risk
18
Assessment (FRA)), and it is suitable to conduct the test at the most appropriate qualification phase22 (the
categories of the tests to perform are described in detail in Annex #1).
Acceptance Criteria
The result of each test is compared to the respective acceptance criteria defined in each qualification phase
to determine whether the result meets the criteria with no deviations. Final test results should be documented
as passed, not applicable, or failed.
• Passed – the test result meets the acceptance criteria, without any deviations with impact.
• Failed - the test result does not meet the acceptance criteria. The results of these tests must be resolved
before an overall conclusion can be made about the validation of the system.
• Not Applicable - it is not necessary to test the functionality in question and document the justification (e.g.
functionalities without any GxP impact).
Quality Risk Management
The introduction of any large-scale integrated information system (i.e. ERP) can lead to significant changes in
processes, tasks and people-related issues51–53. The possibility of risks in the implementation and operation of
the system leads to the deployment of risk management approaches during the system lifecycle54. Application
of risk management focuses on critical aspects of CS in a controlled and justified approach. It is important to
understand the concepts of risk management as it is the basis for an efficient risk-based validation.
ICH Q9 recommends55 that a quality risk management (QRM) should include systematic processes (Figure 11)
designed to coordinate, facilitate and improve decision-making according to the risk.
Figure 11 – Overview of a typical Quality Risk Management process55
19
There are some necessary steps in order to initiate and plan a QRM process such as:
• Define the problem and/or risk question identifying the potential for risk;
• Assemble background information and/or data relevant to the risk assessment.
The second step of a QMR process is a risk assessment to identify hazards and evaluate the risks associated
with exposure to those hazards. In ICH Q9 there are three questions that help identify (what might go wrong?),
analyze (what is the likelihood it will go wrong?) and evaluate (what are the consequences?) the risk55.
The third step is risk control, which aim on decision-making to reduce the risk to an acceptable level and/or
accept the risk. Risk reduction focuses on the mitigation or avoidance of the severity and probability of harm.
Risk acceptance is applied when the risk has no effect on quality and in the cases QRM practices might not entirely
eliminate the risk55.
The output/result of the QRM should be appropriately communicated and documented among involved
areas (e.g., regulators/regulatory entity and industry, industry and the patient or within the company). This
sharing of information about risk and risk management is defined as risk communication55. The company must
include in their QRM a mechanism to risk review or monitor events to gain new knowledge and experience that
might redefine the previous risk acceptance decisions55.
Pharmaceutical industry and regulators can assess and manage risk using internal procedures (i.e., SOPs) and
with recognized and recommended risk management tools such as those referred to in table 855,56.
20
Table 8 – Risk Analysis Methodologies
Risk Analysis
Methodology Functionality Applicability to CSV57
Hazard Analysis
and Critical
Control Points
(HACCP)
Analyze, evaluate, prevent, and
control the risk or the adverse
hazard consequences.
Limited use since this methodology implies a
knowledge of the critical points of the system,
which is not always available (documentation or
source code) in many commercial applications.
Hazard
Operability
Analysis
(HazOp)
Uses guide words to structure the
evaluation of process safety
hazards.
One of the success factors of this methodology is
the completeness and accuracy of the system
specification documentation, therefore, its use is
limited to configured or customized CS.
Fault Tree
Analysis
(FTA)
Identification of real or potential
problems displaying the results as a
tree of faults with the
corresponding failure mode.
Top-down structured failure analysis, deductive to
identify the causes/modes of failure and how their
failure may have been caused.
Little application for CSV.
Preliminary
Hazard Analysis
(PHA)
Uses previous experience or
knowledge of hazards and failures
to identify future ones and estimate
their probability of occurrence.
Conducted at the beginning of a new project when
information of similar projects is available;
Little application for CSV of new systems.
Failure Mode
Effects Analysis
(FMEA) Evaluation of failure modes and
their potential outcomes.
Classify the risk.
Identify mitigation measures.
Methodologies well established and highly
recommended in pharmaceutical industry;
Methodology recommended (FMEA) by GAMP®5
(Appendix M3 of GAMP);
Suitable for CSV (GAMP Category 4 and 5).
Failure Mode,
Effects and
Criticality
Analysis
(FMECA)
21
2. Methodology followed in the dissertation
The methodology adopted for this dissertation consisted mainly of three stages, which are related to the
theme addressed in this work and are illustrated in figure 12:
Figure 12 – Methodology of the dissertation
This work was based on a literature review, which intended to contextualize the concepts of this subject,
highlighting the importance of regulations in the pharmaceutical industry.
An analysis of the system's functionalities was performed in order to assess the various processes that the
system will support, in conjunction with the different user areas of Labatec Farmacêutica S.A followed by a GxP
impact analysis. The URS for the ERP were defined according to a developed methodology.
Lastly, a validation plan was developed following a risk-based approach, employing a risk analysis
methodology (FMEA) to identify and evaluate risks in order to plan the qualification activities to be applied to
the ERP SAGE X3 system.
Lite
ratu
re r
evi
ew ERP systems
Computerised System Validation
Guidelines & Regulations
Warning Letters
Syst
em
ch
arac
teri
zati
on Definition of system
functionalities
GxP Impact Assessment
User Requirements specification
Syst
em
ass
ess
men
t Functional Risk Assessment
22
3. Case Study: Planning of the ERP System Validation in Labatec Farmacêutica S.A.
ERP in Labatec Farmacêutica S.A.
The selection of an ERP the Labatec Farmacêutica S.A project arose from the desire to implement a system
that covers all the business and manufacturing needs.
An initial study of the ERP already implemented in Swiss facility (SAGE X3) was performed in order to
understand which system functionalities were being used to support the processes. For this purpose, an
assessment of the operating procedures was done and possible improvements that were not being explored
were evaluated.
Along with the relevant user areas, the ERP main functions were defined (figure 13), and the processes where
it could be applied were identified. Thus, it was possible to establish a rationale for the development of the URS.
Figure 13 – Main ERP functionalities according to Labatec Farmacêutica S.A. processes
23
System Impact Assessment
Once the system is identified and their functions determined, the impact of the system on product quality
and in the applicable good practices was assessed58. This assessment should categorize whether the system has
direct impact, indirect impact or no impact.
In order to determine if the ERP system should be subjected to validation, a methodology to document the
rationale for the GxP impact assessment was developed and performed, as represented in Table 9.
Table 9 – Impact Assessment Result
Computerised System Name Enterprise Resource Planning
Assessment YES NO
No. (A) Intended use
1
The system is used to create, to control, to modify purchase or receipt data of material
classified as GxP (i.e. supplier/manufacturer approved, name, code, concentration,
specification)?
X
2 The system is used to create, to control or to modify the batches identification (i.e.
item code, batch number, quantities, measures units, conversion factors and etc)? X
3
The system is used to create, to control, to modify or to store information used in a
production or packaging process (i.e. formulas, batch status for release, equipment
status, packaging material status, raw material status, tests specification)?
X
4 The system is used to create, to store data or is used for Quality Control activities
(tests, analysis, analysis methods) for the manufacturing or packaging process? X
5
The system is used to control the warehouse or the distribution activities with GxP
impact or is used to store information about batch distribution than can be used in
Recalls?
X
6 The system supports the maintenance of instruments/equipment considered critical
(i.e. calibration, preventive maintenance) X
7 The system supports, stores or changes product data or reports used by Quality
Assurance to make decision about processes approvals? X
8 The system is used for batch record or batch approval? X
9 Does the system manage critical manufacturing control parameters? X
10 Does the system manage controlled documents? X
24
Assessment YES NO
No. (B) User Area
1 Quality Control X
2 Quality Assurance X
3 Maintenance X
4 Production X
5 Warehouse X
6 Finances X
7 Other: _______________________________________________________________ X
No. (C) GAMP®5 Software Category
1 Category 1- Infrastructure Software X
2 Category 3 – Non-Configured Products X
3 Category 4 – Configured Products X
4 Category 5 – Custom Applications X
No. (D) Associated Infrastructure
1 Hosted in a hardware computer system. X
2 Hosted in a web-cloud infrastructure. X
3 Other: _______________________________________________________________ X
GxP Impact Assessment Result
[ X ] Direct Impact [ ] Indirect Impact [ ] No impact
Required documents/activities:
[ X ] User Requirements Specifications [ X ] Installation Qualification
[ X ] Functional Risk Assessment [ X ] Operational Qualification
[ ] Design Qualification [ X ] Performance Qualification
[ ] The system do not need to be qualified [ X ] Final Validation Report
Comments:
Since the system is already implemented at Swiss Labatec, and the intended ERP is a configurable
commercially available standard software, Design Qualifiction may be omitted as the Installation
Qualification, Operational Qualification and Performance Qualification may be a sufficient indicator of its
suitability.
This assessment was conducted by a multi-disciplinary team consisting of representatives of Quality
assurance, Validation and IT supplier. Considering the intended use for the software, the user areas and the
functions related to GxP activities, the system was categorized as a direct impact system considering the
affirmative answers in the field A. Validation was planned according to the impact of the system and a risk-based
approach strategy was developed.
25
Validation Plan
The VP should consider the main potential risks, and according to the identified risks, establish a methodology
that ensures that the system operates in a controlled manner and that will always produce the expected results.
A risk-based validation strategy was developed with the objective of making validation more appropriate and
targeted. By identifying possible failures, performing risk analysis and developing controls to mitigate them, the
validation team is able to control the risks more effectively.
In the following flowchart (figure 14) is represented a risk-based approach outlined for this work in order to
plan the validation activities for the ERP System, developed in accordance with the principles established in
GAMP®5, ICH Q9 and other applicable guidelines.
Figure 14 – Risk-based approach for CSV
26
Roles and Responsibilities
The activities for the validation of ERP system in Labatec Farmacêutica S.A., will be conducted by a specialized
team containing elements of the production, warehouse, quality and validation areas. Represented in table 10
are the different roles and responsibilities of each area.
Table 10 – Roles and Responsibilities for the validation of ERP System
Roles Description of Activities
User Area • Define the requirements for the functionalities of the system;
• Participate in risk analysis when necessary.
Validation Team
• Identify and analyze carefully the risks identified;
• Develop controls and measures to manage risks;
• Carry out the appropriate tests in the System;
• Write, review and approve the validation documentation.
Quality Assurance
• Initiate the Change Control to start the validation;
• Evaluate deviations that may arise during system validation;
• Identify, analyze and assess the risks associated with regulatory requirements;
• Manage risks as per internal SOP’s.
Supplier
• Make available, whenever required, all information and documents related to the CS,
such as user manuals, configuration and functional specifications;
• Provide the necessary support and control in deviation investigations.
27
Development of the User Requirement Specifications
URS should describe the required functions of the CS and be based on a the GxP impact and applicable
regulations. User requirements should be traceable throughout the lifecycle. The URS should be written in a way
to ensure that the requirements are understood by the system developer and reliably represent the intended
functions.
URS is a key document where all the risk management and validation activities will be supported. The URS
must be clear, concise, testable, comprehensive and categorized. They should reflect specifications and not
design solutions.
In Table 11 are some recommendations to consider when writing URS.
Table 11 – DO and DONT’s when writing URS
DO DON’Ts
Working in conjunction with the validation team, the
VP should be planned concurrently with the
development of the URS59.
Avoid the use of vague requirements such as "must
be 21 CFR Part 11, Annex 11 or GMP compliant"59.
Each requirement must be realistic, complete, unique
(to avoid conflicts between requirements) and must
be objectively verifiable by an authorized method,
e.g. inspection, analysis or test5.
Points should not be listed in the URS indicating that
“the system should be compliant with the
regulations”, but rather it should be designed in such
a way that it complies with the regulations.
Shall be written in a suitable manner so that data will
meet regulatory requirements, as well as the WHO
Guidance on Good Data and Record Management
Practices 24.
Avoid issuing URS without prior knowledge of the
functions of the system and its applicability to the
business. The quality of the system is defined at this
point, if certain requirements are not considered, the
system may be compromised in the following stages.
The URS should be understood and approved by both
user and supplier as these demonstrate the intention
of how the system should be provided by the
supplier.
At Labatec Farmacêutica S.A. the URS were coded according to their category in order to facilitate their
identification and allow a better interpretation of the requirements. Thus, the coding of the URS consisted of the
criteria: AAA_XXX.
Where:
AAA – Is the reference of the type of requirement as describe on Table 12.
XXX – is a three-digit sequential number starting from 001.
28
Table 12 – URS reference for type of requirement
Reference Category Name
GEN_XXX General Requirements
VIS_XXX User Interface (Visualization)
OPE_XXX Operation of the System
SEC_XXX Access Control, Security & Safety
REC_XXX Data acquisition and recording
INT_XXX Interface
DOC_XXX Documentation and training
MNT_XXX Maintenance
In order to establish the importance of the requirements according to the needs of the user, and in order to
assist in the selection of the supplier, the requirements were prioritized into mandatory (M) or desirable (D).
A mandatory requirement is essential to be present in the system to ensure its functions operability and to
ensure compliance with the regulatory requirements and applicable guidelines.
A desirable requirement is a "nice to have" or a custom function that does not need to be present for the
system to operate as intended.
The requirements were defined during a meeting with all relevant user areas, where all the requirements
that each area wanted to have in the system and how these requirements will support the business operations
were discussed.
It is important for all members present at the meeting to have a prior knowledge of the functionalities of the
system to be implemented, reason why a previous mapping of the functions already running in Switzerland ERP
system has been executed.
All applicable and required GxP specifications (such as data integrity, access control or audit trail) were
included, among others required by the user departments and Quality Assurance.
The user requirements developed for the ERP system in Labatec Farmacêutica are represented in tables 13
to 20. Based on the developed URS, the ERP selected was SAGE X3.
29
Table 13 – General Requirements
Nr. Requirement Priority
(M/D)
GEN_001 Graphical interface must be user-friendly D
GEN_002 The language of the system should be English and Portuguese. M
GEN_003 The system should be supported on a Windows 10 computer or other similar versions. M
GEN_004 The system should be available as a web-based and allow access through a web browser
(such as Google Chrome, Internet Explorer or similar browser). M
GEN_005 The system should be able to operate in different platforms such as, computer, tablets
and smartphones. D
Table 14 – URS for user Interface
Nr. Requirement Priority
(M/D)
VIS_001 The system should allow to visualize and trace customers information, such as, name,
address, phone number and/or fax/e-mail. M
VIS_002 The system should be able to allow traceability of batches. M
VIS_003
The system should allow to trace full reconciliation for products &/or batches involved
within the recall from stored information stored such as date of receipt, shipper, internal
article code, product name, batch number, manufacturing date, expiry date, quantity
recalled per batch, quantity released per batch, release date, distribution start date,
distribution end date, quantity consumed on the market.
M
VIS_004 The system should allow the visualization of an updated inventory of all articles. M
VIS_005 The system should allow the visualization of a stock of articles (materials, products,
consumables, etc.). M
VIS_006 The system should allow simple visualization of the stocks of an item per storage
location. M
VIS_007 The system must allow the visualization of movements, article code, date and storage
location of articles. M
VIS_008 The system should allow the visualization the articles according to First Expire First Out
(FEFO) and First In First Out (FIFO). M
VIS_009 The system should allow the visualization and analysis of movements between storage
locations. M
VIS_010 The system should allow visualization by storage location. M
VIS_011 The system should allow the visualization of all the orders (work orders, purchase
orders…), and select by status of approval, article code or date. M
30
Nr. Requirement Priority
(M/D)
VIS_012 The system should allow the visualization and printing of the consumption per
production/packaging order. M
VIS_013 The system should allow the visualization of the consumption by bottom up and down. D
VIS_014 The system should allow the visualization of a summary per item with description,
vendor, and cost (last cost, average cost). D
VIS_015 The system should provide a forecast by item (article) M
VIS_016 The system should provide a list of existing batches (Stock Batch) M
VIS_017 The system should allow the visualization of production debits M
VIS_018 The system should allow the visualization of debits from production per operation M
VIS_019 The system should allow the visualization of the monthly movements and status
changes. D
VIS_020 The system should allow to visualize a history of all batch and article movements. M
VIS_021 The system should allow the visualization of a list of daily movements D
VIS_022 The system should allow the visualization of the registration of returns to the supplier M
VIS_023 The system should allow the visualization of the supplier purchasing values D
VIS_024
The system should allow the visualization of the status of the batches / articles (such as
product bulk, raw material, packaging material, finished product) with the status of
approved, rejected, re-analyzed, re-analyzed for shelf life, quarantined)
M
VIS_025 The system should issue a warning within a defined time of an article expiring its shelf
life. D
VIS_026 The system should allow to issue a list with the articles approaching the end of their shelf
life. M
VIS_027 The system should issue an alert when there is an article stock shortage; D
Table 15 – URS for operation
Nr. Requirement Priority
(M/D)
OPE_001
The system must assign an article code to the article when there is a new entry
according with a predefined rule (e.g., XXXYYYY) where XXX is the category of the article
and YYYY is a sequential number.
M
OPE_002
The system should be able to characterize the articles according to their scope (GxP
scope: raw materials, packaging materials, consumables, bulk product, finished product
manufactured, semi finish product, samples, or only distributed) or non GxP scope
(office material)).
M
31
Nr. Requirement Priority
(M/D)
OPE_003 The system should be able to assign a code by product category (e.g., Active
Pharmaceutical Ingredient (API), Distribution product (NEG), Finished Product (PFI),
Semi-packaged Product - PSC, Bulk Product (PSV)
M
OPE_004
The system should allow the introduction of specifications for each new article (such as
code, name, date, quantity, shelf-life, storage and security conditions, retest date,
effectivity date, potency, and other relevant information).
M
OPE_005 The system should allow that each article code have a unique code linked to a supplier
and to a manufacturer. M
OPE_006 The system should allow to set different status to the article code, such as active, in
development, not usable, not renewed, obsolete, shortage. M
OPE_007
The system should allow to set a batch number, sequential and unique per each code
article according with a predefined rule (e.g., YYXXXX) where YY is the current year of
the manufactured batch and XXXX is a sequential number or in a manual way (for
external batches)
M
OPE_008 The system should allow to enter manually an expiry date and manufacturing date per
each article code. M
OPE_009 The system should generate an expiry date for each batch generated. It shall add a
predefined shelf life as defined in the article from the date of manufacture. M
OPE_010 The system should generate an expiry date for PFI according to the PSV worst case
(shorter validity). M
OPE_011 The system should generate an expiry date for certain articles according to their
category specifications (e.g, packaging material). M
OPE_012 The system should allow to set different status to supplier / clients, such as approved,
qualified or disqualified and in process. M
OPE_013 The system should allow to trace some information for the supplier / manufacturer,
such as address, qualification status, contact, lead time. M
OPE_014 The system should only allow the use of qualified suppliers (such as issue purchase
orders) and approved clients (such as accept orders). M
OPE_015
The system should allow the entry of different status such as for destruction ("R" for
Rejected) and the motive (e.g. expired); In case of approved or restocking of incoming
materials in the ERP (status "A" for Accepted).
M
OPE_016 The system should allow the returned product to be received in “Q” for Quarantine
status. M
OPE_017 The system should allow to update the status of a batch number for “R” - rejected after
reaching the expire date. M
32
Nr. Requirement Priority
(M/D)
OPE_018 The system must manage the articles stock according to FEFO and FIFO. D
OPE_019 The system should allow to change the status assign to a batch number only to users
with authorized profile. M
OPE_020 The system should allow the correction of data according to the designed profiles/
access privileges and the change must be justified. M
OPE_021
The system should allow only the users with a restricted privilege profile (high-level
profile) to change locations, quantities and release operations for article codes
identified as products like narcotic, cold chamber, falsified medicines and with special
conditions for storage and handling.
M
OPE_022
The system should allow a differentiated flow for returned product that requires an
additional approval of Quality Assurance/Qualified Person to be re-integrated on the
stock.
D
OPE_023 The system should allow to configurate displays with selected information to be printed
on labels including barcodes and numbering. M
OPE_024 The system should allow stock inventory and adjustments on locations and quantities
by designed profiles/ access privileges. M
OPE_025 The system should have a stock management function according to diverse categories
of material management (list of articles for analysis and analyzed) M
OPE_026 The system should allow the creation of an inventory of the materials and products used
in manufacturing and distribution activities. M
OPE_027 The system should restrict the correction of quantities for Finished product on A status. M
OPE_028 The system should allow the requisition of reference and retest samples with assigned
location with a field to justify D
OPE_029 The system should allow to configurate based on specific information the creation,
visualization and printing of a sampling Plan with the articles and quantities to analyze. D
OPE_030 The system should allow the requisition and traceability of medical samples with a field
to justify. D
OPE_031 The system should request the status approval for Launched production order and BOM
receipt before it goes to active status. M
OPE_032 The system should allow to request a retest date and a expire date for articles codes
related to raw materials M
OPE_033 The system should allow the creation of storage area locations with specifications (ex:
warehouse, pharmacotheque, intermediate zone between production and warehouse) D
OPE_034 The system should allow the creation of storage locations according to a predefined
code. M
33
Nr. Requirement Priority
(M/D)
OPE_035 The system should be able to enter detailed specifications of storage locations (narcotic,
cold chamber, special conditions, falsified products and others). M
OPE_036 The system should allocate articles according to their specifications in the respective
storage location. D
OPE_037 The system must allow the reversal of a material receipt and to be recorded in an audit
trail. M
OPE_038 The system must allow the reversal/correction of quantities of articles and to be
recorded in an audit trail. M
OPE_039
The system must allow transfer of articles between different storage locations (material
to be destroyed, exits of material that does not follow the normal path, returns, etc.)
according to the authorization of the user.
D
OPE_040 The system should be able to print transfer orders. M
OPE_041 The system should allow transfer of articles between production, laboratory and
warehouse locations. M
OPE_042 The system must allow the printing of labels of the identification of the material
volumes with a barcode and numbered. M
OPE_043
The system shall allow the reprinting of labels of the identification of material volumes
with a barcode and numbered, depending on the access level, indicating that it is a
reprint.
M
OPE_044 The system should allow the reversal of a movement between storage/other locations
and to be recorded in an audit trail. M
OPE_045 The system should automatically issue an inspection plan and sampling plan when a
material receipt is made. D
OPE_046 According to the result of the inspection plan the system should constrain the
movement of the article. D
OPE_047 The system shall automatically print out the inspection plan and sampling plan when a
new inspection lot is opened. D
OPE_048 The system shall automatically print the labels of the respective sampling plan
numbered. D
OPE_049 The system must block quarantined items (“Q”) to be moved to other locations such as
production locations. M
OPE_050 The system should automatically block selected articles in inventory. M
OPE_051 The system should be able to print transport guides and export labels according to the
product information. D
34
Nr. Requirement Priority
(M/D)
OPE_052 The system shall communicate with the weighing area by transferring the
requirements/batch to be weighed associated with the production order number. D
OPE_053 The system should receive the information from the scales terminal whenever each raw
material reaches the need value. D
OPE_054 The system should allow the creation of suggestion orders - WOS, planned orders - WOP
and firm order - WOF. M
OPE_055 The system must control when creating a manufacturing order, all raw materials used
in the manufacturing order are in status A and have valid shelf life. M
OPE_056 The system must allocate the dispatched items to the production/packaging order. M
OPE_057
The system must allow the consumption of materials in each production/packaging
order and to change the quantities in case of returns (material reintegration in the
order).
M
OPE_058 The system must allow the following phase time to be inserted in each
production/packaging order. D
OPE_059 The system should be able to record the recipe name, all machine including the auxiliary
equipment and production timings for each batch/manufacturing order. D
OPE_060 The BOM must perform the potency correction according to the article information (i.e.
API information). D
OPE_061 The system should block the consumption of materials that are not defined in the BOM. D
OPE_062 The system shall allow the quantity of finished product to be entered in each
production/packaging order. M
OPE_063 The system shall allow the quantity of finished product to be corrected before its final
approval. M
OPE_064 The system must allow the correction of consumption before the order is financially
closed. M
OPE_065 The system shall allow the printing of pallet labels according to the product information
in the system, barcode and numbered. M
OPE_066 The system should block the consume material that does not belong to the respective
order. D
OPE_067 The system should be able to manage customer returns; D
OPE_068 The system should record supplier and customer master data; D
OPE_069 The system should be able to print on-screen data to the printer; D
35
Table 16 – URS for Access Control, Security & Safety
Nr. Requirement Priority
(M/D)
SEC_001 System access via authorized user ID and password. M
SEC_002 The system must have a hierarchical access control. M
SEC_003
The system should allow to set differentiate levels of access within the system. Upon
to request to the administrator access to specific functions or modules should be
attributed.
M
SEC_004 The system should allow to have a basic user profile only to consult the modules but
without any possibility to enter data, delete or modify data. M
SEC_005 The system should allow to create unique users identified by a username and
password. M
SEC_006 The system should allow to have an unlimited number of user accounts and access
profiles. M
SEC_007 The system must support access at least to 6 user accounts at the same time in the
system. M
SEC_008 The system must ensure uniqueness in the usernames. M
SEC_009
The system must require passwords to have complexity requirements such as
minimum of characters, not contain the user’s account name, uppercase and
lowercase letters and non-alphanumeric characters.
M
SEC_010 The system must require the user to change his password within a period of time
defined in internal company procedure. M
SEC_011 The system must lock the user account if an incorrect password is entered three
consecutive times. M
SEC_012 The system must have an administration user level that is able to create users, delete
users and unlock user accounts. M
SEC_013 The system should record accesses and report attempted entries; M
SEC_014 The system should link the audit trail with the user that have made the change. M
SEC_015 The user identification on the audit trail should be unique and unmistakable. M
SEC_016 The system must be able to perform periodic and robust back-ups of data. M
SEC_017 The system should archive all data when is no longer needed; M
SEC_018 The system should be able to perform data migration; D
SEC_019 The system should have an anti-virus protection mechanism deployed; D
SEC_020 The system should include automatic logoff after a period of inactivity of 10 minutes; D
SEC_021 The system must have safety measures for data security and ensure that information
remains confidential; M
36
Table 17 – URS for data acquisition and recording
Nr. Requirement Priority
(M/D)
REC_001 The system should allow extracting a comprehensive audit trail with first entry, new
entry, date and author of the change. M
REC_002 The system must generate an automatic audit trail of any modification, creation or
deletion on GxP data. M
REC_003 The system should not allow the users to disable the audit trail function. M
REC_004 The system must ensure that audit trail records are read only, and not editable,
protected from accidental or intentional deletion or modification. M
REC_005 The system should allow viewing and exporting selected parts of the audit trail. M
REC_006 The system should allow to extract list to an industry standard formats like Adobe
PDF and XML in a human readable format. M
REC_007 The system must prevent modification of validated documents. M
REC_008
The system should allow to do an inventory with a list of article codes and batches
in stock, their location and status, receipt date, expire date should be extracted from
the system to an industry standard formats like Adobe PDF and XML in a human
readable format.
M
REC_009
The system should generate Date and hour in a consistent in all documentation
generated by the system.
Date format must be Day Month Year “DD MM YYYY”.
Hour format must be Hour Minute “HH:MM”.
M
REC_010 The system should record every activity with the real date and time expressed in
hour & minutes with the user ID of the person who was logged on to the system; M
REC_011 The system should record article (product) master data in the format of a BOM. M
REC_012 The system should have a MRP system for warning and/or (semi)automatic
generation of purchase orders. D
REC_013 The system should issue alerts to email address or in a dashboard as requested; D
REC_014 The system should be able to create and approve purchase orders according to the
data in the system; M
REC_015 The system should be able to create a customer order; M
REC_016 Creation of work centers for each manufacturing room/process to build product
receipt associated to the BOM (with setup time and production time) D
REC_017 The system should have an editable planning scheme for different work centers. D
37
Nr. Requirement Priority
(M/D)
REC_018
The system should record crucial information like manufacturing date, final bulk
expiry date and storage conditions, and if exists the same information for production
in process should be associated with the bulk product code and printed in the order.
The same with routine sampling.
M
REC_019 Existence of a system location exclusive for delivery of finish bulk batches prior to
packaging that finishes the process D
REC_020 Existence of a system location for bulk packaging materials for the consumption
batch by batch D
REC_021
The system should record, and store information of the production orders
manufactured, and to be manufactured in the future according to the
client/headquarters necessities
D
Table 18 – URS for Interfaces
Nr. Requirement Priority
(M/D)
INT_001 The system should be compatible with android terminals to be used on the
warehouse. D
INT_002 The system should be able to establish an interface with the weighing terminals. D
Table 19 – URS for documentation and training
Nr. Requirement Priority
(M/D)
DOC_001 Confidential Agreement M
DOC_002 Manuals with Glossary M
DOC_003 User Training on the System M
DOC_004 Configuration File M
DOC_005 Installation File M
DOC_006 Functional and Configuration Specifications M
38
Table 20 – URS for maintenance
Nr. Requirement Priority
(M/D)
MNT_001 In the event of a power failure, the system shall ensure no compromise of the data
currently being used; M
MNT_002 If power loss is maintained for a long period of time, the system shutdown must be
performed in a controlled manner; M
MNT_003 The system must have a flexible architecture to introduce improvements, new
modules (with new functionalities) or later adjustments; M
MNT_004 The system must have a Quality Environment where the necessary improvements
are tested prior deployment to production environment. M
MNT_005 Procedures for Change Control Management related to CSV shall exist. M
MNT_006 Procedures for Periodic Review of the system shall exist. M
MNT_007 Procedures for problem resolution shall exist. M
MNT_008 Procedures for system security shall exist. These procedures shall include Physical
Security, Application Security, and Network Security. M
MNT_009 Procedures for Shutdown/Start-up shall exist. M
MNT_010 Procedures for system administration shall exist. M
MNT_011 Procedures for Maintenance shall exist M
MNT_012 Procedures for Back-up and restore shall exist. M
39
Functional Risk Assessment
The FRA documents the measures identified to be taken to mitigate the system risks on product quality,
process or in the applicable good practices. Control measures defined in the FRA are verified during the
qualification activities. In order to conduct a risk analysis, a qualitative FMEA was used in accordance with the
GAMP®5 approach to risk analysis22, and the criteria used in the different steps are represented below. A FMEA
template to apply in functional risk assessments is presented in Annex #2.
Failure Mode Effects Analysis60
This risk analysis intends to:
• Identify the risks associated to the critical functions and parameters of a system;
• Evaluate the impact of the risks on product/process quality;
• Define the measures to be taken to minimize the impact of the risks.
Risk Identification
In this phase, the potential risks are identified. These risks are related to the critical functions and parameters
of the system according to their business and regulatory compliance. The following questions should be used:
• What can fail?
• What is the impact on the fail?
• What external fails may occur?
• What control systems may fail?
Risk Analysis
To be comparable, the risk must be measure. In order to measure the risk, it is necessary to attribute a level
to make possible to quantify the risks. The following parameters should be evaluated to each failure mode
identified:
• Probability [P]
It is the occurrence probability of a risk scenario or event. It can be classified as:
Low: The failure event is rare, happening once at 100 000 cycles;
Medium: The failure may happen at each 1 000 cycles;
High: The failure may happen at each 100 cycles.
• Severity [S]
It is the potential impact that the occurrence of a failure can has on the quality of the product, process or in
the applicable good practices. It can be classified as follows:
Low: the severity of the fault has a low impact on quality; the impact of the fault does not extend in
time;
Medium: failure has moderate severity in quality and may have an effect in the medium term;
High: failure has a high impact on the quality of the product. It has catastrophic consequences that
may extend in time.
40
• Risk Class [RC]
The risk class of each failure is classified by plotting the probability of occurrence (low, medium or high) versus
the severity of the failure (low, medium or high) using a 3x3 Boston grid.
Severity
of
Impact
Risk Probability
Low Medium High
High Level 2 Level 1 Level 1
Medium Level 3 Level 2 Level 1
Low Level 3 Level 3 Level 2
Figure 15 – Risk Class Assessment
Level 1: High impact risk.
Level 2: Medium impact risk.
Level 3: Low impact risk.
• Detectability [D]
It is the evaluation of how a failure can be detected. It can be classified as follows:
High: Detection highly likely.
Medium: Moderate probability of detection.
Low: Detection is unlikely.
• Risk Priority [RP]
The Risk Priority is the classification given to the risk associated to a failure, where control measures will be
assigned. Risk prioritization is determined by plotting the Risk Class (Level 1, 2 or 3) versus the probability of
detection (low, medium and high) using a 3x3 Boston grid.
41
Risk Class
Detection Probability
Low Medium High
Level 1 High High Medium
Level 2 High Medium Low
Level 3 Medium Low Low
Figure 16 – Risk Priority Assessment
High risk: it represents a level of risk that recommends taking actions to mitigate the risk, as well
actions to demonstrate their control.
Medium risk: it is a risk that implies actions to demonstrate that risk is controlled.
Low risk: It is an acceptable level of risk. Action may be taken to mitigate or control the risk, but it is
not mandatory.
Risk Control
Based on the Risk Priority, actions can be taken to demonstrate the control and prevention of failure. The risk
control strategy22 shall be developed taking into account the points referred in Table 21.
Table 21 – Risk Control Strategy
Risk Control Strategy
Identify the root cause that can cause a failure and set a control that prevents that root cause from occurring.
Reduce risk by reducing the probability of failure:
• Introduction of automated checks of data quality;
• Development of operating standard procedures to business process to counter possible failures;
Reduce the risk by increasing the mechanisms for fault detection:
• Introduction of automated controls within the CS being assessed, e.g:
- Data verification checks within the system to reduce the likelihood of data entry errors (input ranges)
- User prompts to verify inputs and alert messages to increase the detectability of user error.
Increase the rigor of verification testing to demonstrate that the CS performs as intended and handle possible
failure events.
Appropriate training and operating procedures for users and system operation.
42
In other cases, the risk identified may be reasonably low or easily detectable and therefore specific controls
are not mandatory. Controls for a given process can be configured in the system when necessary (according to
the user requirements) at the project development stage, such as alerts, data field restrictions, required data
fields or input field prompts for verification. According to the control, the most appropriate test shall be applied
to the respective qualification activity (IQ, OQ or PQ).
For this case study, the functions and parameters of the system that are related to good practices, such as
access control, audit trail, GxP data management, among others, were assessed. For each
functionality/parameter, risks were identified and analyzed following the qualitative risk criteria for FMEA,
assessing the probability of occurrence, severity of failure and its detectability, classifying each failure mode as
high, medium or low. As defined in the validation plan, for each failure mode, controls to decrease the probability
or increase detectability were indicated. For system operation control, tests have been specified to verify the
effectiveness of the controls in place. For control of the risk associated with the user, actions such as proper
training, creation of operating procedures, check the audit trail, review or approval by a user with higher level
profile were also specified. The result of the functional risk assessment is shown in table 22.
43
Table 22 – Risk Analysis Matrix
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
1 Perform the tracking of batches released
for each distributor/market
Missing information; Data
corruption.
In case of the need for a recall, information of the batch and
distributor/market must be accurately stored and available.
• Perform backup of normal operating
data according to approved procedure
(including periodicity).
• Perform recover of data according to
approved procedure.
PQ
Low High Level 2 Low High
2 Support in Customer Return (return of a
product)
Missing information; Data
corruption.
The information of the customer or the batch related to the
return is not available and the batch can’t be traceable.
• Perform backup of normal operating
data according to approved procedure
(including periodicity).
• Perform recover of data according to
approved procedure.
PQ
Low Medium Level 3 Low Medium
3 Visualize and trace customer and
supplier information
Missing information; Wrong
information; Data corruption.
The information of the customer/supplier, such as the
qualification status must be available or it’s not possible to
ensure that the product is only distributed/order to/from
approved customers/supplier.
• Perform recover of normal operating
data according to approved procedure. PQ
Low Medium Level 3 High Low
44
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
4
Allow only the use of qualified suppliers
(such as issue purchase orders) and
approved customer (such as accept
orders)
Disqualified or in process
supplier or customer are
entered into the system as
qualified.
Purchase orders can be issued/accepted for a disqualified or
in process supplier/customer.
• The qualification status of the supplier or
client must be confirmed by a second
authorized person in order to improve the
detectability.
• Perform audit trail to confirm who
added the information in the system.
PQ
Low High Level 2 Low High
The system fails to control and
allows the use of unapproved
or in process of approval
suppliers and customers.
System is not capable of control function.
• Define purchase or client order approval
only for user with higher level profile. IQ
• Perform Accuracy test to check system
capability to control this function. OQ
Low High Level 2 Medium Medium
5 Stock & inventory of manufacturing and
distribution articles
Connection failure and no real-
time update.
Unrealistic data in relation to current stock and inventory.
•Test network connection with fault
tolerance test. IQ
• Verify the availability of a SOP for backup
(including periodicity). OQ
• Perform inventory & stock reconciliation
according to an approved procedure. PQ
Medium Medium Level 2 Medium Medium
6 System automatically block selected
articles in inventory
Article is not blocked when
selected in inventory.
Compromises the real-time status of the inventory. • Perform accuracy test to verify the
system accuracy of control. OQ
Low Medium Level 3 Medium Low
45
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
7 Movements (article code, date, location)
Connection failure and no real-
time update.
Movements are not recorded by the System;
Loss of traceability of movements.
• Record the movements manually and
then update them in the system.
• Perform fault tolerance test.
OQ
Medium Medium Level 2 Medium Medium
Movement is not performed
properly.
Movement to the wrong location, or for the wrong article. • Verify the availability of an operating
procedure and training. OQ
Medium Medium Level 2 Medium Medium
8 Status of the articles (batches, raw
materials, materials…)
Connection failure and no real-
time update of the article
status.
Unrealistic data in relation to current stock and inventory.
• Perform fault tolerance test. OQ
• In case of connection failure record the
status updates manually and then enter
the data in the system.
PQ
Low Medium Level 3 Low Medium
9
Entry of information for each article such
as name, date, quantity, shelf-life,
storage, retest date, effective date
Entry of information in a wrong
field.
During the initial entry of data into the system it is possible
that the user by inexperience in the use of the system can
enter data in the wrong field
• Define a high-level profile approval for
GxP data entry. IQ
• Ensure that the user has adequate
training to avoid errors in the operation of
the system functions.
• Perform data validity test and invalid
case test in order to decrease the
probability of errors to happen.
OQ
• Perform an audit trail to confirm who
added the information in the system. PQ
Medium High Level 1 Medium High
46
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
10
Characterize the article according to
their scope (raw material, packaging
material, bulk product, finished
product…)
Article is allocated in the wrong
category.
User misintroduces the article in the wrong category.
• Ensure that the user has adequate
training to avoid errors in the operation of
the system functions.
• Verify the availability of an operating
procedure and training.
OQ
Low Low Level 3 Medium Low
11 Each article has a unique code linked to a
supplier and/or to a manufacturer
Article code is incorrectly
entered.
In case of recall, return or customer/supplier complaint the
supplier and the manufacturer of the article must be
traceable.
• Verify the availability of an operating
procedure and adequate user training.
• Perform data validity test and invalid case
test.
OQ
Low Medium Level 3 Medium Low
12 Enter manually an expiry date and
manufacturing date per each batch code
User mixes expiry date field
with manufacturing date.
The system should detect once the article expires
immediately.
• Perform data validity test and invalid case
test (such as testing if the system accepts the
expiry date before the manufacturing date).
OQ
• Confirm if the expiry date is in accordance
with the manufacturing date (in batch
record) and with the shelf life of the article.
PQ
Low Medium Level 3 Low Medium
Expiry or manufacturing date
are incorrectly entered.
The article may become invalid earlier than the system
indicates.
• Verify the availability of an operating
procedure and adequate user training.
• Perform Invalid case testing.
OQ
Low High Level 2 Medium Medium
47
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
13
The system assigns an expiry date
according to a predefined shelf life
defined for the article starting from the
date of manufacture.
The expiry date is incorrectly
generated by the system.
The expiry date is incorrectly generated which may lead
to incorrect use of the article or to rejection of a good
condition article.
• Perform output test and input combination
test. OQ
• The expiry date shall be revised and/or re-
entered into the system in accordance with
the batch record by user with higher level
profile.
PQ
Low High Level 2 Medium Medium
The shelf life defined for the
article is incorrectly entered.
The expiry date can be incorrectly generated which may
lead to incorrect use of the article or to rejection of a good
condition article.
• Define a high-level profile approval for
Shelf life introduction in order to improve the
detectability.
IQ
• Verify the availability of an operating
procedure for generating expiry date.
• Ensure that the user has adequate training
to avoid errors in the operation of the system
functions.
• Perform data validity test and invalid case
test.
OQ
Low High Level 2 Low High
The date of manufacture is
incorrectly entered.
User must confirm manufacturing date in batch record.
The initial manufacturing date must be counted from the
date of the first granulation.
• Perform data validity test and invalid case
test. OQ
• Confirm if the expiry date is in accordance
with the manufacturing date (in batch
record) and with the shelf life of the article.
PQ
Low High Level 2 Low High
48
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
14 Configured Labels according to data in
the system
The information in the label is
incorrectly entered.
Wrong barcode and/or article code introduced can lead to the
use of the wrong material.
• Verify the availability of an operating
procedure and adequate user training.
• Perform data validity test and invalid
case test.
OQ
Low High Level 2 Low High
15
Visualization of locations and
management of quantities of articles
identified as narcotic, cold chamber,
falsified medicines and with other
storage and handling conditions.
Special handling conditions
article is not characterized as
such.
User does not categorize the article or introduce it into a wrong
location.
• Perform accuracy test to check audit
trail accuracy and security test. OQ
• Verify the availability of an operating
procedure for warehouse management
and adequate user training.
OQ
Low High Level 2 Medium Medium
Any user is able to change the
location and/or quantities of
articles.
The function is available for all users, or all user profiles have
access to change the location/quantity of the article.
Problems with the reconciliation of articles.
• Perform audit trail to confirm who
added the information in the system.
PQ
Low High Level 2 Medium Medium
16 Record article master data in the format
of a BOM.
BOM consisting of incorrect
information.
A BOM containing incorrect information can have
consequences at the manufacturing level.
• Define BOM approval only for users
with higher level profile. IQ
•Verify the availability of an operating
procedure for record of BOM and
adequate user training.
OQ
Medium High Level 1 Medium High
49
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
17
Entry of different status and the motive,
according to profile/access privileges.
A: Approved
R: Rejected
Q: Quarantine
Article status is misintroduced
“R or Q” status is intered as
“A”.
Rejected or in quarantine article can be used for production
purposes which could seriously compromise the quality of the
product and the process.
• Ensure that the user has adequate
training to avoid errors in the operation
of the system functions.
OQ
• The status must be confirmed by a
second authorized person in order to
improve the detectability.
PQ
Low High Level 2 Low High
Article status is misintroduced
“A” status article is entered as
“R” or “Q”.
Approved article is considered as rejected or in quarantine and
its use is not authorized.
• Ensure that the user has adequate
training to avoid errors in the operation
of the system functions.
OQ
• The status must be confirmed by a
second authorized person in order to
improve the detectability.
PQ
Low Medium Level 3 Low Medium
Any user without the approved
profile can change the status of
the article.
The function is available for all users, or all user profiles have
access to change the status of the article.
• Verify the availability of a SOP
describing the levels of privileges to
access certain functions.
• Perform an audit trail to confirm who
added the information in the system.
• Perform accuracy test to check audit
trail accuracy and security test.
OQ
Low High Level 2 Low High
50
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
18 Update the status of an article for “R”
after reaching the expire date
The system fails to update the
status and a rejected article is
considered “A” status.
An expired material can be use in the manufacturing process.
User need to confirm the expiry date of the article before use. • Perform Accuracy test to verify the
system capability to control this function. OQ
Low High Level 2 Medium Medium
19 Issue and print transfer orders The transfer order is not
printed.
Printer failure or the connection with the printer failed. • Perform fault tolerance test to verify
the connection between the printer and
the hardware.
IQ
Low Low Level 3 High Low
20 System access via authorised User ID and
password
Authorised user can’t access
the system.
User cannot access, contacts support. High detectability. • Perform usability test to verify the
authorized access control. OQ
Low Low Level 3 High Low
Unauthorised user accesses
the system.
High security breach that can compromise data confidentiality
and integrity.
• Perform security test (simulate non-
authorized entry to check the system
detection).
OQ
Low High Level 2 Low High
21 Hierarchical access control
Basic user profile can enter,
modify or delete GxP data.
Error in the definition of user profile/access privileges which
may lead to any user having access to functionalities outside
the scope of their training.
• Test the access levels by performing
security test. OQ
• Perform audit trail to confirm who
added the information in the system. PQ
Low High Level 2 Medium Medium
Authorised user can’t access
specific module or function.
User cannot access, need to contact support. High
detectability.
• Perform usability test to verify if the
user is able to access and respond to
information.
OQ
Low Low Level 3 High Low
51
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
22 Allow multiple accesses to the system
simultaneously System overload.
Difficulty in using the system, can crash, increases the
probability of failure. • Perform stress test and environmental
test (define user access limits). OQ
Medium Medium Level 2 High Low
23 Unauthorised access block
Failure to control forced
attempts to enter the system
with multiple attempts.
User force entry and compromises safety and quality of the
system. • Perform security test (the system can
only allow 3 wrong access attempts). OQ
Low High Level 2 Low High
24 Record accesses and attempted entries
in an audit trail
Incorrect or unavailable Audit
Trail.
Lack of data integrity;
Impossible to consult data;
Unawareness of attempted or successful intrusion.
• Check the Audit Trail data safe storage. IQ
• Perform security test to evaluate
attempted entries. OQ
• Perform accuracy test to check audit
trail accuracy. OQ
Low High Level 2 Low High
25
Record user activities (changes, access
functions) with date and ID user
identification in an audit trail
Incorrect or unavailable Audit
Trail.
Lack of data integrity;
Impossible to consult data;
Unawareness of user activities.
• Check the Audit Trail data safe storage. IQ
• Perform accuracy test to check audit
trail accuracy and security test. OQ
Low High Level 2 Low High
26 Periodic backup of data Backup is not properly done.
Data loss or corruption of GxP data.
It is only detectable when the data is lost.
• Perform accuracy test to check backup
accuracy.
• Verify the availability of a SOP for
backup (including periodicity)
OQ
Low High Level 2 Low High
52
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
27 System shutdown in a controlled manner
in case of power failure Data loss or corruption.
Only detectable when the fault occurs.
Risk of compromising GxP data.
• Perform test to verify if system
performs auto-save until the moment of
failure decreasing the probability of
losing data.
• Perform fault tolerance test to
evaluate the data recovery.
OQ
Low High Level 2 Low High
28 Perform Maintenance of the system The maintenance of the system
is not performed.
Maintenance failures increase the probability of failures
occurring.
Operation of the system can be compromised.
• Verify the availability of a SOP for the
maintenance of the system (including
periodicity).
OQ
• Check if maintenance is performed
properly. PQ
Low Medium Level 3 Medium Low
29 Functional and Configuration
Specifications.
Documentation not available
or updated;
Lack of information available;
Lack of IT knowledge.
Improper installation.
Improper or inadequate maintenance. • Check the availability of the supplier
documentation. IQ
Medium Medium Level 2 High Low
30 System technical documentation
Documentation not available
or updated;
Lack of information available;
Lack of IT knowledge;
Lack of legalization and / or
evidence required.
Improper system installation.
Improper or inadequate maintenance.
Without documentation work cannot be done (low severity).
• Check in the installation the
availability and update of the system
technical documentation.
IQ
Medium Low Level 3 High Low
53
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
31
Procedure to control of username types,
password and recurrence of password
update
Lack of procedure(s);
Procedure(s) not updated.
The operation and security of the system are not carried out as
intended. • Verify the availability of a SOP for user
and password management. OQ
Low Medium Level 3 Medium Low
32 Procedure to Change Control
Management
Lack of procedure(s);
Procedure(s) not updated.
The operation is not carried out as intended. • Verify the availability of a SOP for
change control management with
reference to the assess for CSV.
OQ
Low Medium Level 3 Medium Low
33 Procedure for Periodic Review of the
System
Lack of procedure(s);
Procedure(s) not updated.
The operation is not carried out as intended. • Verify the availability of a SOP for
periodic review (including periodicity). OQ
Low Medium Level 3 Medium Low
34
Procedure for system security (including
physical security, application security
and network security)
Lack of procedure(s);
Procedure(s) not updated.
The operation and security is not carried out as intended. • Verify the availability of a SOP for
system security. OQ
Low Medium Level 3 Medium Low
35 Procedure for system administration Lack of procedure(s);
Procedure(s) not updated.
The operation is not carried out as intended. • Verify the availability of a SOP for
system administration. OQ
Low Medium Level 3 Medium Low
36 Procedure for system maintenance Lack of procedure(s);
Procedure(s) not updated.
The operation is not carried out as intended. • Verify the availability of a SOP for
system maintenance (including
periodicity).
OQ
Low Medium Level 3 Medium Low
54
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P]
Seve
rity
[S]
Ris
k C
lass
[RC
]
Det
ecta
bili
ty
[D]
Ris
k P
rio
rity
[RP
] Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
37 Procedure for backup and restore Lack of procedure(s);
Procedure(s) not updated.
The operation is not carried out as intended. • Verify the availability a SOP for backup
and restore (including periodicity). OQ
Low Medium Level 3 Medium Low
38 Procedure for system operation Lack of procedure(s);
Procedure(s) not updated.
The operation is not carried out as intended. • Verify the availability a SOP for system
operation, including instructions on
system functionalities.
OQ
Low Low Level 3 High Low
39 Training Lack of training. Inadequate system operation.
• Verify the availability of SOPs that
support the user’s training, such as
system operation.
• Ensure that users of the system have
adequate training and the planned
training program is in accordance with
the intended use for the system.
OQ
Low High Level 2 Medium Medium
40 Hardware compatibility Web-based software is not
compatible on hardware.
Web-based application accessed via browser is likely to be
compatible in normal hardware devices (PC, laptop,
smartphone).
• Identify system users and register the
main hardware and operating system
configuration and version.
IQ
Low Low Level 3 High Low
55
As demonstrated, system parameters such as the management of training and operational procedures do
not represent a significant risk associated with the operation of the system since the probability of the absence
of these parameters in the qualification phase is low and easily detectable. The correct implementation and use
of these parameters have to be assessed since they are essential and help to ensure that good practices are
constantly followed.
Possible failures were identified, such as in the generation of data by the system, with an associated risk,
usually medium, and which can be evaluated by performing tests that evaluate the capacity of the system to
generate data accurately and the implementation of review phases by high-level users.
Possible failures related to access control and GxP data management, such as GxP data entry, which in case
of user mistake, can indicate flawed information about the quality status, identification or location of an article,
were also identified. These faults have a high associated risk and therefore, controls must be in place in the
system for detect any failure, such as security measures (for access control), confirmation of the data by the
primary data source (batch record, CoA), review of data entry or with the introduction of restrictions to
functionalities only for users with high levels profiles.
From this risk analysis it can be concluded that risks exist associated with the different functionalities and
parameters of the system and that controls to mitigate these risks should be implemented. The tests that verify
the effectiveness of these controls will be defined and performed in the following qualification phases.
56
4. Conclusions and Future work
The main purpose of the validation is to assure consistent quality in a company's processes. Validation should
be planned considering the overall risks related to the system to be validated, taking into account its complexity,
novelty, intended use and the impact on quality. A risk-based VP should then be followed, according to applicable
methodologies that allow us to determine and characterize the different risks that the system may have.
The strong pressure that the pharmaceutical industries are subject to under regulatory agencies, demands
that all processes are strictly compliant with the applicable guidelines and regulations. This leads the industries
to define their quality management system in order to demonstrate that their internal processes present the
expected quality.
It is important for each company to have a strategic VP, taking into consideration the complexity and risk of
the system, to make use of the guidelines, to have an extensive knowledge of the regulations applicable to CSs
in the pharmaceutical industry.
This dissertation was written in order to be used as a guide for planning the validation of CSs and as a case
study on how the validation of the ERP SAGE X3 was planned in the initial phase of Labatec Farmacêutica S.A. in
Portugal.
During this work, the system was characterized according to its GxP impact, determining that it has a direct
impact. A risk-based validation plan was established defining the validation phases to be followed. The system
requirements were developed based on the needs of the user areas. Moreover, a risk analysis taking into account
possible failures identified for the system's functionalities, was performed, allowing the creation of a baseline
for the qualification activities.
Due to the complexity of the initial phase of the Labatec project, unexpected events, delays and unrealistic
expectations usually occur. Any validation process is a time-consuming activity that requires testing, creation of
documentation and achieve results. Since it was not possible to perform the tests on the system in a timely
manner, for future work I would propose to implement the operational procedures and the preparation of
qualification protocols, as well as the reports. This should be performed based on the tests proposed in this
dissertation, following the risk assessment analysis.
57
5. Bibliography
(1) Vuksic, V. B.; Spremic, M. Case Study of PLIVA Pharmaceuticals Inc. - Aligning ERP System Implementation
with Business Process Change. 6.
(2) Ruivo, P.; Johansson, B.; Oliveira, T.; Neto, M. Commercial ERP Systems and User Productivity: A Study
Across European SMEs. Procedia Technol. 2013, 9, 84–93. https://doi.org/10.1016/j.protcy.2013.12.009.
(3) Labatec Website http://www.labatecpharma.com/ (accessed Feb 21, 2019).
(4) Introduction to Computers: Hardware and Software
http://cs.sru.edu/~mullins/cpsc100book/module02_introduction/module02-03_introduction.html
(accessed Oct 19, 2019).
(5) PHARMACEUTICAL INSPECTION CONVENTION. PIC/S Guidance - Good Practices for Computerised
Systems in Regulated “GxP” Environments. 2007.
(6) Kumar, K.; van Hillegersberg, J. Enterprise Resource Planning: Introduction. Commun. ACM 2000, 43 (4),
22–26. https://doi.org/10.1145/332051.332063.
(7) Panorama Consulting Solutions. 2017 Report on ERP Systems & Enterprise Software; 2017.
(8) Panorama Consulting Solutions. 2018 ERP Report; 2018.
(9) Umble, E. J.; Haft, R. R.; Umble, M. M. Enterprise Resource Planning: Implementation Procedures and
Critical Success Factors. Eur. J. Oper. Res. 2003, 146 (2), 241–257. https://doi.org/10.1016/S0377-
2217(02)00547-7.
(10) Rashid, M. A.; Hossain, L.; Patrick, J. D. The Evolution of ERP Systems: A Historical Perspective. 16.
(11) Watson, E. E.; Schneider, H. Using ERP Systems in Education. Commun. Assoc. Inf. Syst. 1999, 1.
https://doi.org/10.17705/1CAIS.00109.
(12) Pharma 2020: Challenging Business Models - Which Path Will You Take? 24.
(13) ERP, O. 6 Reasons Why Pharmaceutical Companies Need an ERP System. 3i infotech, 2017.
(14) Lumenia Consulting Ltd. ERP in the Pharmaceutical Industry - Complex Functional Requirements Create
Significant Challenges for ERP Systems.
(15) Markus, M. L.; Axline, S.; Petrie, D.; Tanis, C. Learning from Adopters’ Experiences with ERP: Problems
Encountered and Success Achieved. J. Inf. Technol. 2000, 15 (4), 245–265.
https://doi.org/10.1080/02683960010008944.
(16) Sage Group. Enterprise Management Solution Capabilities - SAGE X3; 2017; p 54.
(17) MRP, ERP or MIS? A quick refresher course https://www.voortman.net/pl/company/news/448-mrp-erp-
or-mis (accessed Sep 23, 2019).
(18) Spine Software Systems Pvt. Ltd. Process Flow of Pharma Companies & Need of ERP, 12:45:21 UTC.
(19) SAGE ENTERPRISE MANAGEMENT HISTORY – E2b Teknologies.
(20) RKL eSolutions Staff. Managing 21 CFR Part 11 Compliance with Sage X3.
(21) European Commission. EudraLex Annex 15: Qualification and Validation; 2015.
(22) GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems; ISPE Headquarters [u.a.]:
Tampa, Fla, 2008.
(23) Abraham, J. International Conference On Harmonisation - Good Manufacturing Practice Guide for Active
58
Pharmaceutical Ingredients Q7. In Handbook of Transnational Economic Governance Regimes; Tietje, C.,
Brouder, A., Eds.; 2010.
(24) World Health Organization. Guidelines on Validation - Appendix 5: Validation of Computerized Systems.
2018.
(25) European Commission. EudraLex Annex 11: Computerised Systems; 2011.
(26) Comission of the European Communities. COMMISSION DIRECTIVE 2003/94/EC; 2003.
(27) CFR - Code of Federal Regulations Title 21 - Part 11
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11 (accessed Sep
11, 2019).
(28) CFR - Code of Federal Regulations Title 21 - 820.70
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.70 (accessed Sep 11,
2019).
(29) PHARMACEUTICAL INSPECTION CONVENTION. PIC/S Guidance - Good Practices for Data Management
and Integrity in Regulated GMP/GDP Environments. 2018.
(30) European Commission. EudraLex Volume 4 - Chapter 4: Documentation; 2011.
(31) Data Integrity is the New BUZZ Word for Regulated Companies
https://www.researchgate.net/institution/Waters_Corporation/post/59a6d83adc332d2a6e666b4e_Da
ta_Integrity_is_the_New_BUZZ_Word_for_Regulated_Companies (accessed Feb 21, 2019).
(32) IPA Innovation, Quality and Global Reach. Good Documentation Practice (GDP) Guideline; 2018.
(33) Guidance for Industry - Part 11, Electronic Records; Electronic Signatures — Scope and Application. 12.
(34) Annex 11 and 21 CFR Part 11: Comparisons for International Compliance. In EU Annex 11 Guide to
Computer Validation Compliance for the Worldwide Health Agency GMP; CRC Press, 2015; pp 253–262.
https://doi.org/10.1201/b18315-28.
(35) EduQuest, Inc. Comparison of FDA’s Part 11 and the EU Annex 11.
(36) Commissioner, O. of the. About Warning and Close-Out Letters. FDA 2019.
(37) Encyclopedia of Biopharmaceutical Statistics, Fourth edition.; Chow, S.-C., Ed.; Taylor & Francis: Boca
Raton, 2018.
(38) FDA Warning Letters Archives https://validationcenter.com/product-category/library/fda-warning-
letters/ (accessed Sep 22, 2019).
(39) Commissioner, O. of the. Warning Letters http://www.fda.gov/inspections-compliance-enforcement-
and-criminal-investigations/compliance-actions-and-activities/warning-letters (accessed Sep 22, 2019).
(40) Center for Drug Evaluation and Research. Ipca Laboratories Limited - 01/29/2016
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/ipca-laboratories-limited-01292016 (accessed Sep 19, 2019).
(41) Center for Drug Evaluation and Research. Bedfont Scientific, Ltd. - 02/04/2016
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/bedfont-scientific-ltd-02042016 (accessed Sep 19, 2019).
(42) Center for Drug Evaluation and Research. Polydrug Laboratories Pvt. Ltd. - 04/14/2016
59
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/polydrug-laboratories-pvt-ltd-04142016 (accessed Sep 19, 2019).
(43) Center for Drug Evaluation and Research. F.P. Rubinstein Y Cia SRL - 05/05/2016
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/fp-rubinstein-y-cia-srl-05052016 (accessed Sep 19, 2019).
(44) Center for Drug Evaluation and Research. USV Limited - 510159 - 03/10/2017
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/usv-limited-510159-03102017 (accessed Sep 19, 2019).
(45) Center for Drug Evaluation and Research. Dynavision International LLC - 525321 - 09/05/2017
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/dynavision-international-llc-525321-09052017 (accessed Sep 19, 2019).
(46) Center for Drug Evaluation and Research. Becton Dickinson & Company - 535770 - 01/11/2018
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/becton-dickinson-company-535770-01112018 (accessed Sep 19, 2019).
(47) Jotwani, R. Process ERP, an Ideal Software Solution for Life Science Industries. 2015, 23.
(48) Pharmaceutical Computer Systems Validation: Quality Assurance, Risk Management and Regulatory
Compliance, 2nd ed.; Wingate, G., Ed.; Informa Healthcare: New York, 2010.
(49) Software Validation in a Nutshell! The 5 Minute Guide to Understanding the Principles - Learnaboutgmp:
Accredited Online Life Science Training Courses https://learnaboutgmp.com/computer-system-
validation-csv/software-validation-in-a-nutshell-the-5-minute-guide-to-understanding-the-principles/
(accessed Oct 17, 2019).
(50) ICCBBA. Software Validation.
(51) Common ERP Implementation Challenges and How to Overcome Them. MBAF, CPAs and Advisors.
(52) Kraemmerand, P.; Møller, C.; Boer, H. ERP Implementation: An Integrated Process of Radical Change and
Continuous Learning. Prod. Plan. Control 2003, 14 (4), 338–348.
https://doi.org/10.1080/0953728031000117959.
(53) Dey, P. K.; Clegg, B.; Cheffi, W. Risk Management in Enterprise Resource Planning Implementation: A New
Risk Assessment Framework. Prod. Plan. Control 2013, 24 (1), 1–14.
https://doi.org/10.1080/09537287.2011.597038.
(54) Aloini, D.; Dulmin, R.; Mininno, V. Risk Management in ERP Project Introduction: Review of the Literature.
Inf. Manage. 2007, 44 (6), 547–567. https://doi.org/10.1016/j.im.2007.05.004.
(55) Abraham, J. International Conference On Harmonisation - Quality Risk Management Q9. In Handbook of
Transnational Economic Governance Regimes; Brouder, A., Tietje, C., Eds.
(56) Reddy, V. V.; Gupta, N. V.; Raghunandan, H. V.; Kashyap, U. N. Quality Risk Management in
Pharmaceutical Industry: A Review. 8.
(57) McDowall, R. D. Effective and Practical Risk Management Options for Computerised System Validation.
Qual. Assur. J. 2005, 9 (3), 196–227. https://doi.org/10.1002/qaj.339.
(58) Northeast Biomanufacturing Center & Collaborative (NBC). Introduction to Biomanufacturing - Chapter
60
4: Validation; Global Biomanufacturing Curriculum, 2016.
(59) The five dos and don’ts of writing a URS | Healthcare Packaging
https://www.healthcarepackaging.com/article/five-dos-and-donts-writing-urs (accessed Sep 20, 2019).
(60) International Organization for Standardization. ISO 31010:2009 - Risk Assessment Techniques.
(61) Black-Box Testing - BPM Glossary https://www.businessprocessglossary.com/13107/black-box-testing
(accessed Sep 17, 2019).
61
6. Annexes
Annex #1 – Recommended tests for Risk Control/Mitigation Strategy Tests.
Table a-1 – Recommended Tests
Type of
Test Scope of the Test Description
Stru
ctu
ral T
esti
ng Structural Testing is conducted based on the source code knowledge. These test cases challenge
the control decisions made by the software and the software’s data structures including any
configuration settings.
Structural Testing is usually performed within the unit or module test phase i.e. this type of tests
is carried out by the developer of the application for configured products.
Fun
ctio
nal
Tes
tin
g
Functional Testing is conducted to evaluate the compliance of a system or component with
specified functional requirements and corresponding predicted results61.
Functional testing therefore identifies Test Cases based on the definition of what the software
is intended to do.
Normal Case Testing
Testing to demonstrate the response to the normally expected
inputs; (e.g., checking that a calculation gives the correct result in
response to the expected inputs);
Invalid Case Testing
Testing to demonstrate the response to specified invalid inputs;
(e.g., giving the correct error message in response to an out-of-
range input);
Special Case Testing Testing to demonstrate the response to input values that seem
likely to cause program errors; (e.g., "0", "1", NULL, empty string);
Output Testing Choosing test inputs to ensure that all software outputs are
generated at least once during testing;
Input Combination Testing Testing combinations of inputs to ensure correct outputs.
62
Type of
Test Scope of the Test Description
Per
form
ance
Tes
tin
g
Performance Testing is performed to evaluate the compliance of a system or component with
specified performance requirements.
Environmental Tests Testing to demonstrate that the system is capable of operating
reliably in the specified environment;
Accuracy Tests Testing to demonstrate that the system meets the required
accuracy of measurement or control;
Repeatability Tests Testing to demonstrate that the system is capable of repeatedly
meeting the required performance;
Timing or Response Tests Testing to demonstrate that the system meets the required
timing, throughput or response.;
Load Tests
Testing to demonstrate that the system meets the required
performance whilst operating under realistic high load conditions;
e.g., many users logged at the same time;
Usability Tests
Testing to evaluate the combined performance of the system and
user; e.g., check if the user is able to access and respond to
information.
Ch
alle
nge
Te
stin
g
Challenge Testing is performed to evaluate the robustness of a system or a component under
abnormal operating conditions.
Data Validity Tests
Testing to demonstrate that system is capable of avoiding or
detecting invalid inputs; (e.g., user entries in the wrong format,
values outside of the allowed range);
Security Tests Testing to show that the system offers protection against control
actions or data access by unauthorized users;
Fault Tolerance Tests Testing to evaluate the system’s ability to continue operations in
the presence of faults and to recover when the fault condition
clears; (e.g., network failure, printer failure, recovery of deleted
data);
Stress Tests Testing to evaluate the system’s ability to continue operation
under abnormally high load conditions and to recover when the
condition clears; (e.g., high network traffic);
Environmental Tests Testing to evaluate the system’s ability to continue operation
under extreme environmental conditions.
63
#Annex 2 – FMEA template for Functional Risk Assessment
Table a-2 – Example of FMEA template for FRA
No. Parameter / Function
Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy
Failure Mode
(Possible Failure)
Pro
bab
ility
[P
]
Seve
rity
[S]
Ris
k C
lass
[R
C]
Det
ecta
bili
ty [
D]
Ris
k P
rio
rity
[R
P]
Actions/Tests:
Risk Mitigation/Reduction Strategy
Qualification
Activities
1 [write down the function / system
parameter]
[Write down the what might go wrong?]
[Write down considerations/observations on the
impact]
[write down all the points and/or factors
that is either implemented, planned, or
proposed for implementation in order to
reduce this risk & /or eliminate the risk]
[Refer the
Qualification
Phase the
test should
be
performed]
P S RC D RP
… …
… …
P S RC D RP
2 … …
…
… …
P S RC D RP