{"id":480,"date":"2019-05-06T17:43:29","date_gmt":"2019-05-06T20:43:29","guid":{"rendered":"http:\/\/bpxconsultoria.com.br\/?p=480"},"modified":"2021-06-22T17:45:46","modified_gmt":"2021-06-22T20:45:46","slug":"validacao-de-sistemas-computadorizados","status":"publish","type":"post","link":"https:\/\/bpxconsultoria.com.br\/en\/validacao-de-sistemas-computadorizados\/","title":{"rendered":"COMPUTERIZED SYSTEMS VALIDATION"},"content":{"rendered":"

In this article we are going to discuss about another topic that always raises questions in the pharmaceutical industries\u2019 routine: The Validation of Computerized Systems.<\/p>\n

Why to validate?
\nThe main objective of computerized systems validation is to prove through documented tests that the systems properly fulfill their functions in a consistent and safe way.<\/p>\n

Where to find orientations?
\nThe main guide for the professionals who validates the systems is the GAMP\u00ae5 (Good Automated Manufacturing Practice \u2013 A Risk Based Approach to Compliant GxP Computerized Systems), that is currently in the version 5. However, the access to this document \u00e9 restricted because it is paid and also because it is only available in the English language.<\/p>\n

Besides the GAMP, the FDA (Food and Drugs Administration) 21 CFR (Code of Federal Regulation) Part11 standard establishes rules for the use of electronic records in the life sciences industries.<\/p>\n

What to validate?
\nIt is very common that, after your first contact with the concept of systems validation, you believe that you need to validate everything that has a software. But, calm down! Before you turn on the emergency siren, let\u2019s understand a bit about the CSV\u2019s scope.<\/p>\n

The systems that require validation are called Systems \u201cGxP Relevant\u201d (Good Practices, where the x can be manufacturing, distribution, laboratory, etc.), that is, any and all systems that have an impact on:<\/p>\n

\u2022 Patient\u2019s health;
\n\u2022 Product quality;
\n\u2022 Data integrity.<\/p>\n

It got easier? Probably not that much, right? I understand your anguish, I had also been through it and here is a tip:<\/p>\n

Prepare a document to determine the need to validate or not, with the questions below.<\/p>\n

If any answer of these questions is \u201cYES\u201d, the system must be validated for having impact on GxP:<\/p>\n

\u2022 Does the system store data that implies on the products traceability?
\n\u2022 Does the system manage:
\n\u2022 The automated operation of critical production equipment or individual laboratories (compressor, fluid bed, HPLC, dissolvers, etc.)?
\n\u2022 The automated operation of critical utilities generation (purified water, air conditioning, pure air, water for injection, etc.)?
\n\u2022 The registration of presentations, dosages, raw materials, packaging, strengths, batch sizes, production steps, master formulas, etc.?
\n\u2022 The production planning (production orders, batch numbers, raw materials, packaging, etc.)?
\n\u2022 The materials purchase process (providers\u2019 qualification, control of the orders from pre-qualified providers, quantities, strengths, specifications, etc.)?
\n\u2022 The receipt of materials (batch numbers, sampling plan, physical conditions, damage record, etc.)?
\n\u2022 The storage of materials (status, addressing, movements and transfers, etc.)?
\n\u2022 The weighing central (weighing orders, strengths, fractioning, containers, scales, labels and seals, weighing results, operators, products batches, materials batches, etc.)?
\n\u2022 The production control (manufacture orders, process controls, records, operators, materials, batches numbers, used equipment, use and operation sequences, alarms, samples, etc.)?
\n\u2022 The customer service center (complaints, actions, adverse events, etc.)?
\n\u2022 Documentation (emission, distribution, obsolete versions control, training, etc.)?
\n\u2022 Quality systems (out-of-specification results, self-inspection, deviations, changes control, records of results of raw materials analysis, packaging or products, periodic review, etc.)?
\n\u2022 Training program (scope, instructors, attendance lists, certificates, etc.)?
\n\u2022 Equipment (plan and execution of maintenance, plan and execution of calibration, plan and execution of qualification, etc.)?<\/p>\n

Anyway, all computerized systems that have a direct or indirect impact with the production of the product or impact on its traceability, need to be validated!!!<\/p>\n

Is every system validable?
\nGreat! Now you have already mapped out all the systems that need to be validated, Let’s go to work, right? Not yet! We have one more check to do before elaborating all documentations. The point is: not every system is validable. And now? How to do this mapping? And what to do if the system not fulfill the prerequisites?<\/p>\n

Let\u2019s go!<\/p>\n

The validation of a computerized system does not resume itself on performing tests to confirm the proper functioning of a software, and its interactions with the hardware. It must also take note to the aspects related to the infrastructure, security, data maintenance, among others.<\/p>\n

Firstly, it must follow the compliance requirements with FDA 21 CFR Part11, it means, briefly, the system must include:<\/p>\n

\u2022 Capacity to store critical data of operations or controls with relevance related to GxP, inviolable electronics files (database with backup and restore);
\n\u2022 Audit Trail \u2013 who entered the system, when, what time, what they did, why they did, where they did it?
\n\u2022 Control so that the entries and data modifications are carried out only by authorized persons (security measures, such as the use of passwords, personal code, keys or restricted access to terminals, must be used);
\n\u2022 Different levels of passwords for users and individual users;
\n\u2022 Electronic signature (e.g., login + password to conclude critical steps)
\n\u2022 Strict control of password recovery;
\n\u2022 Ability to record the access attempts by non-authorized persons;
\n\u2022 Ability to record the authorized accesses, including the user, time and date;
\n\u2022 Possibility of printing the electronically stored data.<\/p>\n

If any item above is not attended by the system that you are analyzing, it cannot be validated.<\/p>\n

And so? Do we just let it go? The answer is NO.<\/p>\n

This system must pass through the mitigation process, that basically means to elaborate procedures that cover the failures of the system. For example: the system does not have field to date and sign the electronic records, so for this system it must be used a paper record.<\/p>\n

In case the mitigation or upgrade is not possible, the system exchange must be consider, as it cannot be validated.<\/p>\n

Valuable tip: if you are acquiring a new system, you must request these requirements to the supplier before the purchase.<\/p>\n

How to validate?
\nNow that your mapping is done, let\u2019s work:<\/p>\n

Who is responsible for validating?
\nThe best option is a multidisciplinary team, but every company has your own division. The best option, in my opinion, is the managing by the validation team with the help of the engineering and IT team for the elaboration\/revision of the documents, and the tests elaborated and executed by the user or provider.<\/p>\n

Computerized Systems Inventory
\nThe inventory of computerized systems is used for identify every existing systems in the company.<\/p>\n

The document must contain the following information:<\/p>\n

\u2022 The system identification, description and version;
\n\u2022 The identification of the system owner;
\n\u2022 The GxP impact assessment (high, medium, low);
\n\u2022 The system status (validated, not validated, etc.);
\n\u2022 The validation report number, if the system has already been validated;
\n\u2022 The interfaces with other systems.<\/p>\n

The inventory must contemplate computerized systems, embedded computerized systems, that is, coupled to an equipment (compressor, stove, HPLC, etc.), spreadsheets and systems infrastructure.<\/p>\n

Validation Documentation \u2013 Life Cycle
\nWe call the \u201clife cycle\u201d the events present throughout the whole time of use of a determined system. These events basically consist of: definition of the specifications of a system for the purchase, acquisition of the system, installation, release, routine use and retirement.<\/p>\n

The following figure shows the general approach of the life cycle of computerized systems (V-model).<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Source: GAMP\u00ae5 (Good Automated Manufacturing Practice \u2013 A Risk Based Approach to Compliant GxP Computerized Systems), ISPE, 2008
\nBoth the GAMP5 and the ANVISA Guide detail the exact life cycle required for each type of system and separate as follows:<\/p>\n

\"\"<\/p>\n

To better clarify, the following table shows the main documents that must be provided for the validation life cycle of a computerized system.<\/p>\n

\"\"<\/p>\n

What should be tested?<\/strong><\/p>\n

\u00a0<\/strong>All the raised risks in the risk assessment must be verified\/tested, because, after all, each one has its particularities. However, some risk scenarios are commonly presented and must be tested, examples:<\/p>\n

 <\/p>\n

In the Installation Qualification it is needed to verify:<\/p>\n