IT systems validation in the Life Science industry

Jan Pietrzyński
Jan Pietrzyński
Senior Front-End Developer
March 31
4 min
Table of Contents

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.

Jan Pietrzyński
Jan Pietrzyński
Senior Front-End Developer
  • follow the expert:


What our partners say about us

After carefully evaluating suppliers, we decided to try a new approach and start working with a near-shore software house. Cooperation with Hicron Software House was something different, and it turned out to be a great success that brought added value to our company.

With HICRON’s creative ideas and fresh perspective, we reached a new level of our core platform and achieved our business goals.

Many thanks for what you did so far; we are looking forward to more in future!

hdi logo
Jan-Henrik Schulze
Head of Industrial Lines Development at HDI Group

Hicron is a partner who has provided excellent software development services. Their talented software engineers have a strong focus on collaboration and quality. They have helped us in achieving our goals across our cloud platforms at a good pace, without compromising on the quality of our services. Our partnership is professional and solution-focused!

NBS logo
Phil Scott
Director of Software Delivery at NBS

The IT system supporting the work of retail outlets is the foundation of our business. The ability to optimize and adapt it to the needs of all entities in the PSA Group is of strategic importance and we consider it a step into the future. This project is a huge challenge: not only for us in terms of organization, but also for our partners – including Hicron – in terms of adapting the system to the needs and business models of PSA. Cooperation with Hicron consultants, taking into account their competences in the field of programming and processes specific to the automotive sector, gave us many reasons to be satisfied.


PSA Group - Wikipedia
Peter Windhöfel
IT Director At PSA Group Germany

Get in touch

Say Hi!cron

    Message sent, thank you!
    We will reply as quickly as possible.

    By submitting this form I agree with   Privacy Policy

    This site uses cookies. By continuing to use this website, you agree to our Privacy Policy.

    OK, I agree