Abstract
The purpose of this paper is to present a Quality Management System (QMS) for computer systems validation and to identify and demonstrate the validation process on a practical case of a pharmaceutical company. Based on the European and the US legal requirements, we define QMS for computer system validation elements. Validation process example based on the use of a general V-model provides a thorough understanding of the actual validation implementation in practice. Computer system validation in a concrete organization can be implemented, based on general and specific standard operating procedures which form the QMS. Planning, Specifying, Development/ Building, Verification and Report validation activities are presented through process diagrams based on a practical Supervisory Control and Data Acquisition (SCADA) manufacturing computer-aided system validation example. Empirical part employed two research strategies: a single case study and action research. Presented computer system validation QMS and process can provide a guideline for all companies where computer systems are important. Although the presented QMS and process for the computer system validation are related to a specific pharmaceutical company case and its legal requirements, the experience from this highly regulated industry can be appropriately used in other less regulated industries. For verification of the proposed model, they need to be further tested within the pharmaceutical and other less regulated industries.
Keywords: Quality Management System, computer systems, validation, V-model, pharmaceutical industry
Sažetak
Cilj ovog rada je prezentacija sustava upravljanja kvalitetom (Quality Management System - QMS) za validāciju računalnih sustava te prikaz validacijskog procesa na praktičnom slučaju farmaceutske tvrtke. Na temelju europskih i američkih pravnih zahtjeva, definiramo QMS za validaciju elemenata računalnog sustava. Primjer procesa validacije, zasnovan na korištenju općeg V-modela, pruža detaljno razumijevanje praktične implementacije validacije u praksi. Validacija računalnog sustava u konkretnoj organizaciji može se temeljiti na općim i specifičnim standardnim operativnim procedurama, koje formiraju QMS. Validacijske aktivnosti planiranja, specificiranja, razvoja/izgradnje, verificiranja i izvještavanja se prezentiraju korištenjem procesnih dijagrama, zasnovanih na praktičnom primjeru validacije računalnog sustava za upravljanje proizvodnjom Supervisory Control and Data Acquisition (SCADA). Empirijski dio rada koristi dvije istraživačke strategije: studiju slučaja i akcijsko istraživanje. Predstavljeni procesa validacije, kao i primjer računalnog sustava za upravljanje kvalitetom mogu pružiti smjernice za sva poduzeća, kojima su računalni sustavi značajni. Iako se prezentirani QMS i proces validacije računalnog sustava zasnivaju na primjeru konkretnog farmaceutskog poduzeća i njegovih pravnih zahtjeva, iskustva iz visoko regulirane industrije se mogu na odgovarajući način koristiti i u manje reguliranim industrijama. Za verifikaciju predloženog modela, potrebno ih je dalje testirati, kako u farmaceutskim, tako i u drugim, manje reguliranim industrijama.
Ključne riječi: sustav za upravljanje kvalitetom, računalni sustavi, validacija, V-model, farmaceutska industrija
1.INTRODUCTION
In today's world, when we operate with electronic records, the possibility of changing or copying the contents of electronic records, without leaving any visible trace of the change, is extremely high. According to the European Compliance Academy (2011a, p. 8), even in the case of the use of computer systems, regulatory authorities want to ensure data integrity through reliable systems that detect and display errors. To ensure the integrity of the data, the regulatory authorities require the computer systems validation in accordance with their requirements. The world's leading regulatory bodies that set minimum conditions and limitations, both in general and in the field of computer-aided systems in the pharmaceutical industry, are the US Food and Drug Administration (FDA) and the European Medicines Agency (EMA) (European Commission, 2013a, 2013b; US FDA, 2013a, 2013b). Pharmaceutical companies are expected to establish a quality system at all levels of the organization and assure traceability of production and supportive processes (MetricStream, 2014). The paper deals with the computer system quality assurance in the pharmaceutical industry, where data integrity is crucial (Sai et al., 2019; Ranbaxy Laboratories Limited, 2014, pp. 1-20), since today there is virtually no production process that is not regulated and controlled by a single, or multiple computer systems.
The regulation of computer system validations is, on the one hand, very general, but on the other, it states quite clearly what is required from an organization. According to Velkovrh Remec (2007), both the US and the EU legislations require the validation of all critical procedures, processes and systems and the education of all individuals, involved in the process. Regulatory bodies also give numerous recommendations for the implementation of specific systems validation. In the field of computer system validation in the pharmaceutical industry, the well-known professional manual of the International Society for Pharmaceutical Engineering Good Automated Manufacturing Practice- ISPE GAMP5 (2008) has been developed. ISPE GAMP5 interprets regulatory requirements for the computer systems validation and aids in setting up a quality system for validating computer systems.
In terms of quality of computer systems in the pharmaceutical industry, we distinguish between three concepts. The first is to create a quality model, where we move from legal requirements to the first drafts and frameworks, defining what we need to provide in the field of computer systems in the pharmaceutical industry. From these drafts, we define standard operating procedures, which interpret regulatory requirements in more detail, and form the elements of the Quality Management System (QMS) for computer system validation. The third step is execution of validation activities on an actual computer system, by using the established QMS.
Based on legal requirements of the pharmaceutical industry, Sallubier and Rusjan (2017) developed a general model of QMS for computer systems validation and concluded that we can distinguish between general and specific standard operating procedures. They emphasised the need of testing the appropriateness of the presented general model by using it within the pharmaceutical industry.
The purpose of this paper is to present a QMS for computer systems validation and to identify and demonstrate the validation process on a practical case of a pharmaceutical company. QMS is established, based on the European and the US regulatory requirements, which are basic and general, and, therefore, cannot be directly applied within a company. Instead, every regulatory requirement needs interpretation and formalization in the company procedures, and we must assure that following activities are performed, according to these interpretations and procedures.
The paper addresses two basic research questions:
1. What are the standard operating procedures forming a specific pharmaceutical company QMS for computer system validation;
2. How to perform the validation of the computer system, considering the pharmaceutical industry regulatory requirements.
To answer these questions, the paper first outlines the legal requirements governing the pharmaceutical industry and by comparing them defines the basic QMS elements for computer system validation. This is followed by an example of the process of validating a computer-supported production system in the pharmaceutical industry, which provides a thorough understanding of the actual validation implementation in practice and its connections with regulatory requirements. As a basic starting point for identifying the process of validating a computer system, we used the V-model methodology approach to validation, which is the most widespread within the area of computer-based system validation in the pharmaceutical industry.
2.METHODS
The paper identifies the European and the US legal requirements governing the pharmaceutical industry by using descriptive and comparison methods. Then, we design a QMS for computer systems validation, by using classification and compilation methods.
The usefulness of the designed QMS was tested on a specific case within pharmaceutical company. In this empirical part, we, therefore, employed two research strategies; a single case study and action research. We intended to analyse whether the general and specific standard operating procedures, which form the QMS, provide an appropriate framework for the validation of a concrete project of Supervisory control and data acquisition (SCADA) manufacturing computer system implementation. The validation example was based on the use of a general V-model for validation of computer systems. A single case study may be justifiable, when the research topic is in its early stages (Eisenhardt, 1989), when it is used to persuade (Siggelkow, 2007), and when used as a representative/typical, or a revelatory case (Yin, 2009). Action research is a practice-oriented interventionist research method that aims to address a phenomenon in its practical context, i.e. to solve a practical problem through collaboration between researchers and practitioners. It is focused on the improvement of both practice and body of knowledge through intervention (Gill, Chew, 2019). Being a participatory approach, it is ideally suited to monitoring change process and outcomes (Koshy et al., 2011). Testing practical computer system validation against conceptual frameworks follows the suggestion that action research should have implications beyond the immediate project and that results could inform other contexts (Saunders et al., 2009), in our case other less regulated industries.
3.REGULATORY REQUIREMENTS IN THE PHARMACEUTICAL INDUSTRY
When considering current European regulatory requirements, we rely on the EU Legislation rules for governing medicinal products in the European Union, called EudraLex. EudraLex guidelines consist of 10 volumes and computer systems are described in Volume 4, which regulates good manufacturing practice (GMP). Although Volume 4 includes several chapters and annexes, only two of them are directly related to the validation of the computer systems: Chapter 4, which describes good documentation practices and Annex 11, which describes computer systems (European Commission, 2013a). Qualification and validation in general are described in Annex 15.
As stated in EudraLex, Volume 4, Chapter 4 (European Commission, 2011a, p. 2), document management is a key part of quality assurance and of operating in accordance with good manufacturing practice. Annex 11 relates to all types of computer systems, which are classified as GxP. GxP refers to systems used in good practices, where »x« represents a variable. So GxP can for example be GMP (Good Manufacturing Practices) or GLP (Good Laboratory Practices) etc. IT applications and IT infrastructure, which are subject to qualification activities, are also included into these guidelines. Regulation emphasise that using computer systems instead of manual operations shall not have negative impact on the product quality, process control or quality assurance and should not increase the process overall risks (European Commission, 2011b, p. 2).
According to the European Compliance Academy (2011a, pg. 11) the following are the key points from Annex 11 that should be considered in computer system validation:
* Described principles apply for GxP and not only for GMP.
* Risk based approach should be considered in all areas.
* Electronic records are acceptable.
* During validation, the focus is on checking system design,
* External suppliers of GxP relevant IT systems are taken into consideration,
* Milestone between the validation phase and the operational phase of IT systems should be clear
US regulatory agency FDA and its regulatory requirements can be found in the section Code of Federal Regulations (CFR). For validation of computer systems, 21 CFR Part 211 and 21 CFR Part 11 are important. Number 21 represents the section of foods and medicines, Part 211 represents current good manufacturing practices (cGMP), and Part 11 represents electronic records and electronic signatures (U.S. Food and Drug Administration - FDA, 2013a, 2013b).
Crucial for the computer system validation from FDA point of view is 21 CFR Part 11, which covers electronic records and electronic signatures and includes (U.S. Food and Drug Administration - FDA, 2013b):
* System controls (closed and open type of computer system) - system validation, electronic records security, unauthorized access controls, system change management etc.,
* Controls for electronic signatures - signee identification, timestamp, responsibility (e.g. author, reviewer, approver),
* Connection between electronic signature and electronic data,
* Users identification - biometrical identification, username and password, user administration etc.
Lopez (2012) states that 21 CFR Part 11 requirements are considering more technical and procedural controls in case of electronic records (creation, modification, storage, archiving, copy, restoration) and electronic signatures. Annex 11, on the other hand, covers all activities, needed for computer system validation. To be able to validate computer systems, we, therefore, also need to consider a broader picture, which includes the regulatory requirements 21 CFR Part 211 (for computer systems subsections D ( 211.68) and E ( 211.80).
4.ESTABLISHING QUALITY SYSTEM FOR COMPUTER SYSTEM VALIDATION
To develop a quality system for the computer systems validation, the legal requirements must be respected and fully implemented in the quality system. Establishing a successful quality system requires creating instructions and policies (which represent standard operating procedures - SOP), that summarize the parts of the legal requirements, which are then followed by all employees in the organization. We can distinguish between general and specific standard operating procedures (Sallubier and Rusjan, 2017).
The general SOP, developed in case of a pharmaceutical company, which are intended for use within most of the activities and business processes of the organization, are as follows:
* Procedures for good documentation practice;
* Procedures, which determine approaches and time periods of archiving for different records types in both, electronic and paper form. This is important for record accessibility and is needed, e.g. in cases of product recalls from the market, if investigations of deviations from good manufacturing practices need to be conducted, or in other cases when records are evidence of proper implementation of processes (e.g. manufacturing, laboratory);
* Procedures which prescribe trainings for users, e.g. frequency and type of trainings. From the computer system point of view, this is very important, because when a system's functionality is developed or upgraded, consequentially, the work instructions or user manuals are changed accordingly. From the point of view of regulatory requirements, this means that all computer system users should be adequately trained, based on the latest valid work instructions or user manuals;
* Procedures, which prescribe internal audits implementation in the organization;
* Procedures, which prescribe supplier audits, in regard to their quality system appropriateness and their regulatory requirements knowledge;
* Procedures, which monitor deviations from good practices management. These procedures can also include guidelines for conducting investigation of deviations;
* Procedures, which prescribe suppliers and suppliers' contracts management.
In addition to the general SOP, which support multiple business processes in an organization, we also need specific SOP for the implementation of computer system validation. These are procedures that are related to the specifics of validation, and the most important ones in the case of a pharmaceutical company are:
* The overall general procedure that prescribes the computer systems validation;
* Execution of High-Level Risk Assessment;
* Assessment of computer system supplier;
* Management of changes in computer systems;
* Computer system access control and authorization management;
* Performing backups, archiving electronic records, and restoring a computer system;
* Computer system operational continuity assurance;
* Computer system Configuration management;
* Computer system Incident management;
* Computer system inventory;
* Computer system periodic reviews;
To assure appropriate use of the SOP social aspect is of critical importance. Sing et al. (2018) identify and explain common problems related to social issues challenges in organization and governance, execution, training, and personnel.
5.COMPUTER SYSTEM LIFE CYCLE WITH VALIDATION CASE EXAMPLE
5.1.Computer system life cycle
To ensure regulatory compliance, as well as that the computer system operates within the required specifications, we must consider the computer system life cycle (PIC/S, 2007, p. 7), which provides an understanding of the requirements that have to be met, regarding the computer system and systematic development activities, implementation, application and computer system retirement. Figure 1 shows the computer system life cycle concept as a whole, composed of four phases, as indicated in the GAMP5 (International Society for Pharmaceutical Engineering - ISPE, 2008, p. 26) and the five fundamental activities for the computer system project phase/validation - planning, specifying, building/development, verification and report.
The project phase is subject to the complete computer system validation, where we follow the V-model. In the computer system validation and IT applications, the V-model is primarily used for the purpose of minimizing the quality risks of the computeraided system, or IT applications and for improving quality (International Society for Pharmaceutical Engineering - ISPE, 2008).
Once the project phase is completed, the computer system enters the operating phase, which means the computer system production use. Once the system is in regular use, users can request the system upgrade and add new functionalities to the computer system, but there may also be a process change, or some other change to the computer system that needs to be implemented. In the case of changes that do not significantly affect the computer system operation, we do not need to revalidate the entire computer system, but only the part of the system that has changed. Therefore, the validation scope is smaller.
Over time, when a computer system can no longer be used to the full extent, or is removed from operational use for any other reason, we move into the retirement phase, where such a system needs to retire, according to the prescribed general procedures. Upon computer system retirement, the greatest attention should be given to the retention of GxP relevant electronic records (data) on a computer system, so that they remain accessible to authorized persons and fully readable for a number of years (usually 10 years) after the computer system retirement. In case when the retired computer system is replaced by a new computer system, we can perform data migration into a new system, thus ensuring the data availability. The project phase will be explained in more detail, since it is of key importance, if we want to successfully validate the computer system.
5.2.Validation process example
Computer-based systems validation is logically defined as a project (project phase), as illustrated in Figure 1, since the computer system validation ends, when the system enters the production phase (operational use). To facilitate illustration of the computer-based system validation through a concrete case, we provide key information about the selected computer system.
A technologist in the production of a pharmaceutical company wants to replace a manually driven process with the automatic one, to be able to improve production process control and management. This individual must continuously review and adjust critical process parameters, such as temperature, speed, and time of mixing in the production process so that parameters do not exceed specified limits. Their activities also include sequencing of production steps, in accordance with the instructions of the batch record. In this case, the technologist is a user, who begins writing User Requirements Specifications (URS) for a computer system. In our case, this system is SCADA, which enables monitoring and controlling the production process. Therefore, the technologist in our case needs functionality of the SCADA system, displaying on the screen the necessary information and enabling them to check the historical process data, e.g. graphically (x axis: time, y axis: critical parameters value, e.g. temperature, mixing speed, mixing time....). Important functionality needed also include the temperature and the mixing speed regulation. Additionally, it would make sense to have recipes stored on the SCADA system, and consequently provide automatic step sequencing and execution of the functions of tempering, mixing, etc. Another user requirement is that production can run in two modes; manual and automatic mode, where technologist only checks the SCADA system occasionally and intervenes only, when corrections are necessary.
Examination of regulatory requirements and professional literature (US FDA, 2002, pp. 1-34; US FDA, 2003, pp. 1-9; US FDA, 2004, pp. 7-8; US FDA, 2006, pp. 3-24; US FDA, 2013a; US FDA, 2013b; European Commission, 2011a, pp. 2-5; European Commission, 2011b, pp. 2-9; European Compliance Academy, 2011a, pp. 2-12; European Compliance Academy, 2011b, pp. 3-46; European Compliance Academy, 2011c, pp. 3-31; International Society for Pharmaceutical Engineering - ISPE, 2008, pp. 65-79; PIC/S, 2007, pp. 1-50; Huber, 2012) leads us to the computer system validation process model, described in the next section.
Through the process diagrams, we present an example of the SCADA computer production system validation process, composed of planning, specification, building/development, verification, and report sub-processes.
5.3.Computer system project phase/ validation process
5.3.1. Planning sub-process
Planning sub-process diagram (Figure 2) shows first activities that should be implemented in case when a new computer system is introduced.
A more detailed description of the specific steps within the planning sub-process is presented below.
[K1] New system requirement
The user in the production is thinking about a new computer-based system that would give them useful information, regarding the production process and enable the management and control of the production process. Specifically, the user is considering the SCADA system.
[K2] Create User Requirement Specification (URS)
The user writes down his ideas of the computer system, in our case - the SCADA system. Each requirement has its own unique identifier (e.g. URS-01 etc.), in order to assure traceability of the requirements in the next steps of validation and to help preventing omitting any of the desired system functionalities in the process of the computer system development. Unique identification facilitates control of whether all system functionalities were tested.
The technician, who is a SCADA system user and an expert in the production process management field, usually does not have sufficient knowledge of computer systems regulations, and therefore the quality assurance (QA) manager, an expert in the field of computer systems (eCompliance), gets involved in the process. In our case, the QA manager adds additional system requirements for data integrity management (e.g. data deletition prevention, user data access restrictions, system access levels etc.), requirements for alarm monitoring, and versioning of recipes stored in the computer supported system. An individual at this position also adds requirement for enabling events history, which can show us who worked on the SCADA system, what they were doing, when and, under certain conditions, why they took a certain step. Additionally, the same person establishes the rules for controlling access to the SCADA system, periodic scans of the SCADA system, managing deviations from good manufacturing practice, managing changes on a computer system, etc. Other participants, contributing to identifying the requirements, are those responsible for health, safety, and environment (HSE) and information security officers. The result is creation of an URS [R1] document.
Table 1 provides an example of an URS document with three very simple requirements for the computer-based system functionality: in the first column, we define a unique request identifier (ID) for the purpose of ensuring traceability; in the second column, we specify the request for a computer-supported system, and the third column specifies the requirement criticality, in terms of the level of importance related to this requirement. For example, we can say that the requirement is Essential, Important, or Desired.
[K3] Create High Level Risk Assessment (HLRA)
With HLRA, we perform the original computer-based system classification - GxP relevance of the computer-based system and the computer system/application categorization. With the purpose to ensure easier approach to validation, computer systems are classified into one of the GAMP categories that represent a standard for computer systems in the pharmaceutical industry (International Society for Pharmaceutical Engineering - ISPE, 2008, pp. 128-132; Tedstone, 2012; McDowall, 2010, pp. 2231). As far as the SCADA system categorization, we determined it belongs to the GAMP4 category (for controlling and managing production), being a configurable computer system. In our case, platform (e.g. Proficy iFix) on the SCADA system will be modified and configured by an integrator (supplier), according to our business needs and the URS.
In HLRA, we also determine if the computer system is 21 CFR Part 11 relevant or not (we ask ourselves whether the system will store electronic records or use electronic signatures). In our case, the computer system will store process data that are classified as GxP relevant, therefore the system falls under 21 CFR Part 11 regulatory requirements. Electronic signatures will not be used. In addition, in HLRA, we determine information security (ISEC) impact, health, safety and environment (HSE) impact and impact on personal data. On the basis of the HLRA [R2] result, we decide which computer system validation activities are needed to properly validate the system.
[K4] Conduct Supplier Assessment
Since in our case URS [R1] is sent to several integrators/suppliers of supervisory computer systems, it is necessary to carry out an assessment of suppliers before choosing the best one, in order to assess that the supplier is able to develop computer systems, in accordance with the pharmaceutical industry standards and company internal standards. The assessment shall be recorded in the Supplier Evaluation Report [R3] document. In case that we already conducted supplier assessment in the past (e.g. 5 years) and supplier obtained positive assessment results, the assessment implementation is not necessary, when validating a new computer system/application. Nevertheless, we conduct the supplier assessment once again, if the supplier has been gone through a major organizational change.
[K5] Create Validation Plan (VP)
VP [R4] is a document describing the computer system validation method and principles for validating a computer system. The basis for producing VPs are URS [R1] and HLRA [R2]. We also consider the Supplier Evaluation Report [R3]. VP describes, on the aggregate level, which activities are planned and should be conducted for successfull system validation, which internal SOP and general procedures should be updated, which trainings should be conducted and who needs to be trained, which documents will be created during the validation process, who will draw them up, who will review them and who will approve the validation documentation.
5.3.2. Specifying sub-process
When the new computer system basis is defined and HLRA and VP are developed, we begin to develop the computer system functionality and specifications, based on the approved URS. The sub-process diagram - Specifying (Figure 3) shows details of the key steps for conducting these activities.
A more detailed description of the specific steps within the sub-process Specifying is presented below.
[K6] Create Design Documents
URS [R1] is the basis for creating the Functional Specification (FS), the Software Design Specification (SDS) and the Hardware Design Specification (HDS). The documentation is created by the computer system supplier, or, alternatively, produced by the company, when the computer system is internally developed. In our case, the monitoring/controlling system SCADA is developed by an external supplier, which creates the design documents and sends us the documents for review and approval.
In design documents, the suppliers describe how they see and understand the computer system, according to the given URS, while it is desirable to indicate the references to the URS ID, as shown in Table 2. Only in such a way, it can be ensured that the supplier will create a computer system in accordance with the URS. Table 2 presents an example of system functionalities described in FS.
When reviewing the FS, we note all disparities with the given URS and the whole process is formalized into Design Qualification (DQ). If no discrepancies are detected during the inspection, this should nevertheless be documented and formalized in the DQ.
[K7] Conduct Design Qualification (DQ)
In our SCADA system case, at this point we receive the design documentation from the supplier for review and approval (FS, SDS and HDS [R5]). Since it is in our interest to obtain such a computer system, as defined in the URS [R1], at this stage, we need to review of whether the design documentation provided by the supplier actually covers all of our URS requirements. This is important, as the supplier will build the computer system exactly as it has been defined in FS, SDS and HDS. After completing the comparison between the URS and the FS, SDS and HDS, appointed responsible persons approve the record that was created, when review of the documents was conducted. It is formally called the design qualification - DQ [R6]. In the event that deviations from the URS have been detected in the DQ, the supplier must update the design documentation to embrace all URSs, or the user may limit its requirements for the computer system and create new URS.
It is important to emphasize that, in the pharmaceutical industry, the functionality of a computer system can only restricted, if it does not have any impact on regulatory requirements. However, we cannot limit the requirements, imposed indirectly by the regulatory authorities, in any way, since, in this case, we validate a computer system that does not comply with the prescribed regulations from the start.
[K8] Conduct (Functional) Risk Assessment (FRA)
After confirming FS, SDS and HDS [R5] and considering this documentation together with URS [R1], we produce the FRA [R7], in which we evaluate each of the URSs, according to GxP computer system individual functionality criticality. We evaluate the possible risks we could encounter, in the event of a failure or nonperformance of each functionality, assess the frequency at which these events can occur, the criticality of these events, in terms of impact on product quality, patient safety, safety at work, etc. and we evaluate the possibility of detecting an improper operation or error. Based on the results of each computer system functionality criticality assessments, we decide what kind of testing will be selected for each functionality. The tests can be simple or complex, and each decision needs to be explained and commented on, in relation to each functionality, i.e. we need to explain why we have chosen a certain type of testing.
Therefore, the evaluation and description of risks are implemented for the events where the computer system would not function in accordance with, in our case, the functionalities specified in FS. Where the risk of the system not operating as intended is high, the appropriate Installation Qualification (IQ), Operational Qualification (OQ) and Performance Qualification (PQ) testing of the computer system are performed at the verification phase.
An example of risk analysis is shown in Table 3, where GxP criticality of the system functionalities is evaluated (YES/NO), the impact of errors/deviations, the possibility of an error/deviation, and the possibility of not detecting an error/deviation are determined (H - high impact/possibility; M - mean impact/possibility; L - low impact/ possibility).
5.3.3. Development/Building sub-process
Figure 4 shows the inputs required for the construction of a computer system, as well as the result that follows - a developed computer system and the related technical and user documentation.
A more detailed description of the specific steps within the sub-process of Development/building is presented below.
[K9] System/application development and documentation
At this stage, we start with the computer system construction (in our case - the SCADA system). In development, the basic principles, defined in the VP [R4], must be taken into account, while the main documentation for development are FS, SDS and HDS [R5]. The result is a computer system that complies with the URS, and in our case, the supplier is also obliged to produce technical and user documentation [R9]. All users are required to study them closely before using the computer system.
5.3.4. Verification sub-process
As a part of the verification, we verify that the computer system works in accordance with the users' expectations. As shown in Figure 5, this is checked by IQ, OQ and PQ tests.
More detailed description of specific steps, within the sub-process of Verification, is presented below.
[K10] Test Planning (according to VP [R4])
When a computer system is developed (a SCADA system, in this case), it must pass robust testing to prove that it works faultlessly and in accordance with the specifications. Validating a computer system scope and methodology is prescribed by the VP, and the Test plan [R10] further describes which IQ, OQ and PQ tests are required. When we have a developed and approved tests plan, we write the IQ [R10.1], OQ [R10.2] and PQ [R10.3] test specifications, where we define what we test, how to perform the test, and what is the expected result.
[K11] Testing
We test the system, in accordance with the test plan [R10] on pre-approved test specifications IQ [R10.1], OQ [R10.2] and PQ [R10.3], which are based on the results from the FRA. Installation of a computer system is tested with: an IQ test, which is a documented verification that the computer system is installed in accordance with the pre-approved specifications (International Society for Pharmaceutical Engineering, ISPE, 2008, p. 209, International Society for Pharmaceutical Engineering - ISPE, 2014); OQ test, which is a documented verification of pre-approved specifications that computer system performs as intended throughout all anticipated operating ranges (International Society for Pharmaceutical Engineering, ISPE, 2008, p. 334, International Society for Pharmaceutical Engineering - ISPE, 2014a) and PQ test, which is a documented verification that the system is capable of operating and/or controlling (in our case production) processes during operation in its specified production environment in accordance with the pre-approved specifications (International Society for Pharmaceutical Engineering - ISPE, 2008, p. 284, International Society for Pharmaceutical Engineering - ISPE, 2014b). The results of completed test specifications, obtained after the tests, are called test reports. This gives three sets of IQ test reports [R11.1], OQ test reports [R11.2], and PQ test reports [R11.3]. In cases where an error occurred in the course of testing and the testing was not successful or was only partially successful, this is documented as a test deviation. Both deviations as well as the relevant test reports are summarized in the Test and Deviation Report [R11] document.
If we look at the continuation of our case, it is clear from Table 4 that both functionalities of a computer system need to be tested with the OQ test. The test specification itself must be approved before the testing starts, as the test steps after the approval of the test specification are carried out on a copy of the approved test specification. The expected result, appropriateness, date, and signature are recorded manually in the fields provided for that purpose during the test implementation. In Table 4 we present an example of the OQ test specification, with the manually entered text being greyed out in the table.
[K12] Deviation management
If the test report [R11] indicates that the computer system deviations are recorded, we have to eliminate them. The method of removing the deviations depends on the error type. In these cases, it may also be necessary to correct the design of the computer system itself. The deviation is successfully resolved when repeated tests are successfully completed without deviations.
[K13] Create Traceability Matrix (TM)
What we demanded from the computer system supplier is defined in the URS [R1] and what we actually obtained is in FS, SDS and HDS [R5]. We have also examined the possible deviations, by comparing FS, SDS, HDS and URS and documented them in the DQ [R6]. It is, also, necessary to provide traceability, where it is evident, in a transparent manner, whether all URS have been considered in the design documents (this is already checked in DQ) and which tests (IQ, OQ, PQ) were used to test these requirements. To start the creation of TM [R12], there is no need to wait for the computer system verification, as we can start to build it earlier (during the design qualification - DQ). This ensures the first part of the traceability between URS and FS, SDS and HDS. The second part is provided by IQ, OQ and PQ tests, where we connect the design documentation with test reports. As already mentioned, each user's request is marked with a unique identifier (ID), so that we can guarantee the traceability of document designs and tests. If we find out that we have failed to test one of the computer system functionality, this must be documented and, retrospectively, we must perform testing.
Once the tests are completed, we can build the whole TM, to verify and ensure that all the required URS functionalities were duly considered by the supplier and tested, in accordance with the FRA results. TM for our example is shown in Table 5.
5.3.5. Report sub-process
Figure 6 shows last activities needed before the release of the computer system into production and operational use.
A more detailed description of the specific steps within the sub-process Report is presented below.
[K14] Conduct User Training
Before the system goes into production and operational use, it is necessary to ensure that all (prospective) users of the computer system are trained, by using the Technical and User documentation [R9]. It is also necessary to train users on instructions or company procedures that describe the process and workflow, controlled by the computer system. The training of users is documented in the Training report [R13].
[K15] Create Validation Report (VR)
When all the activities envisaged in the VP [R4] are properly completed, this is listed in VR [R14]. A validated VR means that the computer system (in our case - the SCADA system) is successfully validated and can be routinely operated without any restrictions. The last approval date on VR means the computer system validation date (CSV date).
6.DISCUSSION
The paper addresses two research questions. The first one is related to the standard operating procedures included in a specific pharmaceutical company QMS for computer systems validation.
In accordance with this question, the paper identified standard operating procedures, representing the elements of the quality system for the validation of computer systems in conformance with the requirements of the European and US legislation, governing the pharmaceutical industry. Today, one of the major challenges in designing a QMS in the field of computer systems are either wrong, or simplified interpretations of regulatory requirements. Errors in content or non-conformance with regulatory requirements often occur, because of lack of understanding of computer usage and computer system definitions, and/or lack of understanding how computer systems work. Although the regulatory requirements are basically general, the key to defining and designing a proper QMS is understanding and correct interpretation of regulatory requirements, combined with the knowledge and understanding the actual operation of computer systems. Finally, for a successful computer system validation, we also need to understand the actual work processes. The presented established QMS for the computer system validation is the result of the case of a specific legal requirements interpretation, related to a pharmaceutical company.
In accordance with the second research question on how to perform the computer system validation, considering the pharmaceutical industry regulatory requirements, we studied the basic validation process elements of a computer-aided system. To this end, we used the action research method in conjunction with the case study to test the usefulness of a general V-model and determine sub-processes for all stages of the computer system validation process, considering the regulatory requirements. The paper defines the validation process for a computer system and presents and explains it on a practical example in the pharmaceutical industry. The study confirms that the V-model is an appropriate basis for the validation of computer systems in the pharmaceutical industry and that the established QMS, consisting of the general and specific standard operating procedures, represents an appropriate framework for the implementation of computer system validation. The experience from this highly regulated industry, however, can be appropriately used in other, less regulated industries, to provide the basic purpose of validation, where ensuring data integrity is a key requirement for operation of the computer systems.
The paper contributes to understanding of interpretation of regulatory requirements in the computer system validation field in the pharmaceutical industry. We do not validate computer systems to successfully undergo inspections, but rather to fully ensure the data integrity, to minimize quality risks of a computer system or IT applications and to improve the overall product quality. It is important for the pharmaceutical industry that all suppliers and integrators of computer-aided systems, working with pharmaceutical companies at the GxP level, be aware that the set of regulations, consequently, applies to them, as well. They must be able to demonstrate compliance with the regulatory requirements and, in addition, the regulations and internal standards of the pharmaceutical company, with which they cooperate. Pharmaceutical companies are obliged to carry out audits of the suppliers and integrators with whom they cooperate, and these assessments are becoming increasingly rigorous in the computer systems field.
The presented structure of the QMS has been designed for a specific pharmaceutical company, operating in a highly regulated environment. The quality system elements shown also represent merely a framework for operational computer system validation. Therefore, future work should be focused on testing the appropriateness of the presented QMS structure within other pharmaceutical companies. Similar limitation is related to the use of a single case study for identification of process validation elements. Using a single case study enables the exploration of a particular field, problem, or situation in depth and in relation to a specific context, in our case, as determined by the regulatory framework. In order to verify the presented validation process, it is necessary to add additional case studies, within the same context, i.e. the pharmaceutical industry. In addition, the appropriateness of presented QMS structure and validation process, or respectively, the need for their adaptation and/or simplification, in another context, e.g. less regulated industries, should also be investigated.
7.CONCLUSION
This paper identifies elements of computer systems validation QMS and process, for a specific case of a pharmaceutical organization. In the pharmaceutical industry, the computer system should be validated in accordance with the regulatory requirements. Based on the European and US legal requirements, we defined general and specific standard operating procedures, which represent QMS elements for computer system validation in a pharmaceutical organization. The use of the QMS, which meets the strict pharmaceutical industry legal requirements, is not limited to it, but its elements are also applicable to other industries. The presented QMS can provide guidelines for all companies that need to develop an appropriate framework for computer systems validation and implementation of effective management of computer system validation processes.
With the production computer system validation process example in the pharmaceutical industry, we assure a more profound understanding of computer system validation implementation in practice, with the emphasis on meeting pharmaceutical industry regulatory requirements. As a basic premise, we use the V-model methodology to approach the validation. Planning, specification, development/building, verification and reporting, as the key five activities of the project/validation of a computer system, are presented, by using process diagrams, based on a practical validation example of a SCADA manufacturing computer-aided system.
Received: 26. 12. 2019 Original scientific paper
Accepted: 14. 11. 2020 UDC 005.6:004
DOI: https://doi.org/10.30924/mjcmi.25.2.1
References
1. Eisenhardt, K.M. (1989). Building Theories from Case Study Research. The Academy of Management Review, 14 (4), 532-550.
2. European Commission. (2011a). EudraLex - Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Chapter 4: Documentation, available at: http://ec.europa.eu/health/files/eudralex/ vol-4/chapter4_01-2011_en.pdf (accessed 25 February 2017).
3. European Commission. (2011b). EudraLex - Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Annex 11: Computer Systems, available at: http://ec.europa.eu/health/files/eudralex/vol-4/annex11_01-2011_en.pdf (accessed 25 February 2017).
4. European Commission. (2013a). EudraLex - Volume 4 Good manufactoring practice (GMP) Guidelines, available at: http://ec.europa.eu/health/ documents/eudralex/vol-4/ (accessed 25 February 2017).
5. European Commission (2013b). EU Legislation - Eudralex, available at: http://ec.europa.eu/health/documents/ eudralex/index_en.htm (accessed 25 February 2017).
6. European Compliance Academy (2011a). Introduction & Welcome. ECA Education Course - Computer Validation The GAMP5 Approach. Vienna, Austria: Concept Heidelberg GmbH.
7. European Compliance Academy (2011b). Laws, Regulations and Guidelines for Computer and Control Systems. ECA Education Course - Computer Validation The GAMP5 Approach. Vienna, Austria: Concept Heidelberg GmbH.
8. European Compliance Academy (2011c). The GAMP5 Approach to Computer Systems Validation. ECA Education Course - Computer Validation The GAMP5 Approach. Vienna, Austria: Concept Heidelberg GmbH.
9. Gill, A.Q, Chew, E. (2019). Configuration information system architecture: Insights from applied action design research. Information & Management, 56 (4), 507-525.
10. Huber, L. (2012). Computer System Validation - Tutorial, available at: http://www.labcompliance.com/tutorial/csv/ (accessed 18 January 2014).
11. International Society for Pharmaceutical Engineering - ISPE. (2008). GAMP 5: A Risk-based Approach to Compliant Gxp Computer Systems. Tampa, Florida: International Society for Pharmaceutical Engineering.
12. International Society for Pharmaceutical Engineering - ISPE. (2014a). ISPE Glossary of Pharmaceutical and Biotechnology Terminology, available at: http://www.ispe.org/glossary?term= Installation+Qualification+%28IQ%29 (accessed 26 April 2014).
13. International Society for Pharmaceutical Engineering - ISPE. (2014b). ISPE Glossary of Pharmaceutical and Biotechnology Terminology, available at: http://www.ispe.org/glossary?term= Operational+Qualification+%28OQ%29 (accessed 26 April 2014).
14. Koshy, E., Koshy, V and Waterman, H. (2011), Action research in Healthcare, 1st ed., Sage Publications Ltd., London.
15. Lopez, O. (2012). For Life Science Professionals, Annex 11 and 21 CFR Part 11: Comparisons for International Compliance, available at: http:// www.mastercontrol.com/newsletter/ annex-11-21-cfr-part-11-comparison. html (accessed 25 February 2017).
16. McDowall, R. D. (2010). Understanding and interpreting the GAMP5 life cycle models for software. Spectroscopy, 25(4), 22-31.
17. MetricStream (2014). Systems Validation for 21CFR Part 11 Compliance, available at: http://www. metricstream.com/insights/sys_validation.htm (accessed 25 February 2017).
18. PIC/S (2007). Pharmaceutical Inspection Co-Operation Scheme Guidance - Good Practices For Computerised Systems In Regulated Gxp Environments, available at: http://www.picscheme.org/pdf/27_pi011-3-recommendation-on-computerised-systems.pdf (accessed 23 December 2013).
19. Ranbaxy Laboratories Limited (2014). Data Integrity, available at: http://www. slideshare.net/skvemula/presentationon-data-integrity-in-pharmaceutical-industry# (accessed 21 May 2014).
20. Sallubier, T., Rusjan, B. (2017). Oblikovanje sistema kakovosti za validacijo računalniških sistemov - primer farmacevtske industrije, Revija za univerzalno odličnost, 6 (3), 274-291.
21. Sai, D.C., Bhavyasri, K., Rambabu, D. (2019). Role of Computer System Validation to Safeguard Data Integrity in Pharmaceutical Industry-A Review, International Journal of Pharmaceutical Science Invention, 8 (1), 35-41.
22. Saunders, M., Lewis, P. and Thornhill, A. (2009), Research Methods for Business Student, 5th ed., Pearson Education Limited, Harlow.
23. Siggelkow, N. (2007). Persuasion with case studies, Academy of Management Journal, 50 (1), 20-24.
24. Singh A., Singour, P., Singh, P. (2018). Computer system validation in the perspective of the pharmaceutical industry. Journal of Drug Delivery and Therapeutics, 8 (6), 359-365.
25. Tedstone, B. (2012). Computer Systems Validation. Computer Systems Validation and Quality Assurance blog, available at: http://computersystemsvalidation.blogspot.com/2012/11/ GAMP-Software-Category.html (accessed 27 April 2014).
26. U.S. Food and Drug Administration - FDA (2002). General Principles of SoftwareValidation; Final Guidance for Industry and FDA Staff. U.S. Department Of Health and Human Services Food and Drug Administration, available at:
27. http://www.fda.gov/downloads/ MedicalDevices/Device Regulationand Guidance/GuidanceDocuments/ ucm085371.pdf (accessed 25 February 2017).
28. U.S. Food and Drug Administration - FDA (2003). Guidance for Industry Part 11, Electronic Records; Electronic signatures - Scope and Application. U.S. Department of Health and Human Services, available at: http://www.fda. gov/downloads/RegulatoryInformation/ Guidances/ucm125125.pdf (accessed 25 February 2017).
29. U.S. Food and Drug Administration - FDA (2004). Pharmaceutical cGMP's for The 21St Century, A Risk Based Approach, Final Report. U.S. Department Of Health and Human Services Food and Drug Administration, available at: http://www.fda.gov/downloads/ Drugs/DevelopmentApprovalProcess/ Manufacturing/QuestionsandAnswerson CurrentGoodManufacturingPracticesc GMPforDrugs/UCM176374.pdf (accessed 25 February 2017).
30. U.S. Food and Drug Administration - FDA (2006). Guidance for Industry, Quality Systems Approach to Pharmaceutical CGMP Regulations, available at: http://www.fda.gov/ downloads/Drugs/.../Guidances/ UCM070337.pdf (accessed 25 February 2017).
31. U.S. Food and Drug Administration - FDA (2013a). CFR - Code of Federal Regulations Title 21, Volume 4 - Part 211 Current Good Manufacturing Practice for Finished Pharmaceuticals, available at: http://www.accessdata. fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=2n (accessed 26 December 2013).
32. U.S. Food and Drug Administration - FDA (2013b). CFR - Code of Federal Regulations Title 21, Volume 4 - Part 11 Electronic Records; Electronic Signatures, available at: http://www. accessdata.fda.gov/scripts/cdrh/cfdocs/ cfcfr/cfrsearch.cfm?cfrpart=n (accessed 26 December 2013).
33. Velkovrh Remec, B. (2007). Validation in pharmaceutical industry, available at: http://www.scribd.com/ doc/23022819/VALIDACIJE (accessed 25 February 2017).
34. Yin, R.K. (2009), Case study research: Design and methods, 4th ed., Sage, Thousand Oaks.
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer
© 2020. This work is published under https://creativecommons.org/licenses/by-nd/4.0 (the “License”). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.
Abstract
Cilj ovog rada je prezentacija sustava upravljanja kvalitetom (Quality Management System - QMS) za validāciju računalnih sustava te prikaz validacijskog procesa na praktičnom slučaju farmaceutske tvrtke. Na temelju europskih i američkih pravnih zahtjeva, definiramo QMS za validaciju elemenata računalnog sustava. Primjer procesa validacije, zasnovan na korištenju općeg V-modela, pruža detaljno razumijevanje praktične implementacije validacije u praksi. Validacija računalnog sustava u konkretnoj organizaciji može se temeljiti na općim i specifičnim standardnim operativnim procedurama, koje formiraju QMS. Validacijske aktivnosti planiranja, specificiranja, razvoja/izgradnje, verificiranja i izvještavanja se prezentiraju korištenjem procesnih dijagrama, zasnovanih na praktičnom primjeru validacije računalnog sustava za upravljanje proizvodnjom Supervisory Control and Data Acquisition (SCADA). Empirijski dio rada koristi dvije istraživačke strategije: studiju slučaja i akcijsko istraživanje. Predstavljeni procesa validacije, kao i primjer računalnog sustava za upravljanje kvalitetom mogu pružiti smjernice za sva poduzeća, kojima su računalni sustavi značajni. Iako se prezentirani QMS i proces validacije računalnog sustava zasnivaju na primjeru konkretnog farmaceutskog poduzeća i njegovih pravnih zahtjeva, iskustva iz visoko regulirane industrije se mogu na odgovarajući način koristiti i u manje reguliranim industrijama. Za verifikaciju predloženog modela, potrebno ih je dalje testirati, kako u farmaceutskim, tako i u drugim, manje reguliranim industrijama.