IT systems validation in the Life Science industry

The notion of validation is inextricably related to implementing complex IT systems in the pharmaceutical industry.

It is an extremely important process of which the implementation stage is but one of the elements, continuing until the system is withdrawn from use. This article is dedicated to the topic of validating computerized systems as part of an implementation project, which will be explained on the basis of the six (6) most important steps.

What is a validation of IT systems?

Validation of computerized systems is a set of actions aimed at providing documented proof that will convince us that the system is actually capable of achieving the intended results, and acts in accordance with initial assumptions. How do we do that?

These are the six (6) steps that we must take:

I What are the requirements such a system must satisfy?

Any implementation of an IT system is intended to support, automate, or optimise the carrying out of a business process. Consequently, a particular organisation is usually aware of the process they want to support, and they have a vision of how to do it. So, the first step is to draw up a list of requirements. User Requirements are comprised of both the functional requirements corresponding directly to the supported business process, and the non-functional requirements that correspond, among others, to safety, efficiency, or system interface. Remember about legal requirements when drawing up a list of requirements for systems that will support the pharmaceutical industry.

II Validate? How?

Once we know what the system is going to support, one must consider its criticality. During this step, we should be able to assess whether the system meets the criteria of criticality, from the GxP perspective, and whether it should be validated. What is it about? The key element is assessing whether the system supports elements of the business process that can impact the following:

• Patient health;
• Quality of a medicinal product;
• Data integrity.

If correlation is clearly visible, the answer is simple – validate it!

III How is the system supposed to work?

Each individual function of the system or elements of configuration support corresponding requirements. While in the next step, make a list of all functions, elements of system configuration and expansion, and then combine them with the corresponding requirements. The intent is to provide a system that meets user requirements, so one must be able to unambiguously define each of the functions that correspond to each individual requirement, and make sure that all requirements are covered and carried out in the system.

Obviously, in addition to a standard specification of system functionalities, it will be necessary to draw up a technical specification.

IV Risk? How does one prevent that?

There are risks associated with each individual system function. They must be identified and evaluated. Each risk is evaluated, in terms of its impact on the following: patient health, quality of a medicinal product, data integrity, probability of occurrence, and possibility of detection. Then, one must evaluate the risks that are acceptable, and the ones that require restrictive actions. There are various methods of risk analysis, and mature organisations frequently use their own, well-proven schemes. The most popular ones include the GAMP 5 and FMEA risk analysis methods.

The most frequently applied restriction methods include additional tests, procedures, operation manuals, training courses, and the so-called function reconstruction – sometimes “protections” can be “built into” a particular function of the system.

One must bear in mind that implementing restrictive actions requires redoing risk analysis!

V Tests!

When the system is ready, make sure that it works as needed. Start with tests carried out at the code level, e.g. integration tests or code review. Then, make sure that all components have been installed correctly (IQ), whether the system works as intended (OQ) (in terms of its functional requirements). If these tests are successful, it is time for final tests (PQ) that are usually carried out by end users, who verify whether the system supports the business process currently run in a company, and confirm that the intended goal has been reached, i.e. the system satisfies the intended use. Should any system malfunction be identified at any of the steps, they need to be analysed, corrected, and re-tested (redo the erroneous tests, or the tests that were affected by malfunctions).

Obviously, all tests must be performed formally, i.e. accompanied by appropriate documentation, remembering to obtain proofs of their successful outcomes. Finally, we need to prove that the system works correctly.

VI Summary

When the system is ready, make sure that employees are trained and provided with SOPs, prior to the official commissioning of the system. Satisfying the aforementioned assumptions and implementing the system correctly in production enables summing up all the undertaken actions and commissioning the system.

From the formal perspective, we need to draw up a validation report that contains all the actions we have carried out. The report must list all departures from the initial plan accompanied by a short statement of reasons. If the report identifies actions that were not carried out on time, but which were non-critical for the system validation, they need to be listed and accompanied by an explanation of the method that will be used to track their implementation.

Naturally, we must always remember to keep the validated status of the system, and to correctly carry out and control the following aspects: change management, management of incidents and problems, user and access management, backup procedure, data recovery procedure, and many others.