Are you a manufacturer having difficulties in verifying and validating the software used during manufacturing? Are you part of the QA / RA office (Quality & Regulatory Affairs) and your manager has entrusted you with the difficult task of designing the processes for an OTS (Off the Shelf) SW validation and you do not know how to address these challenges?

Well, you have definitely come across the right content for you!

First of all, the validation activity of a certain process must be part of the VMP – Validation Master Plan – therefore part of a specific Validation Plan whose purpose is to ensure that all the equipment, facilities and processes that can affect the product quality, effectiveness or integrity are validated.

The manufacturing process, regarding the software use during manufacturing, must be therefore validated and included in the VMP.

The GMP – Good Manufacturing Practices – state that “it is a good manufacturing requirement to identify the necessary validation activities in order to demonstrate the control of the critical aspects of particular operations”. Significant changes brought to installations, equipment and processes that are likely to affect product quality must be validated in order to ensure that the process leads to the desired result.

So, how do you exactly validate the software used during manufacturing?

It is not possible to validate a software without defining and documenting the following requirements:

  • Define INPUTS and OUTPUTS
  • Specify the functions to be performed and how the user interacts with the software
  • Define the system’s response
  • Define all the values that can be accepted by the software
  • Define the performance requirements
  • Define the user interfaces, internal and external interfaces
  • Define the errors and how to manage them
  • Define the usage environment: Hardware (HW) and Operating System (OS)
  • Define all the security requirements to be implemented

Based on these requirements deriving from risk management, all possible causes of danger that can lead to a software FAIL must be clearly identified in order to make sure that what was implemented do not lead to a process FAIL.

The test cases should be performed (according to the VMP) and the results should be recorded and evaluated to determine whether they support the conclusion that the software is indeed validated for its intended use.

By the end of the validation process, the manufacturer must possess the following documentation:

  • The definition of user requirements
  • The validation protocol used
  • Acceptance criteria
  • Tests and the results
  • A validation summary

And, of course, the proof that the software has been validated for its intended use.

The aforementioned considerations also apply to OTS software. More often than not, the product documentation is not readily available, nor disclosed by third party vendors. Thus, whenever possible and depending on the risk class of the device, it is recommended that the device manufacturer perform audits of the vendor’s design and development methods employed during the construction of the OTS software.

This audit must demonstrate that, based on the safety and effectiveness requirements of the medical device to be manufactured, the vendor’s verification and validation procedures of the OTS software are both sufficient and appropriate.

Some OTS manufacturers do not allow audits. Consequently, their OTS must be treated and validated as a “black box”, implementing specific procedures based on previous requirements which demonstrate the safety and effectiveness of the software used.


THEMA - Logo TRASPARENTE_smallIng. Andrea Franceschini
Product Manager – QA/RA Consultant


Would you like to be always updated about Thema’s activities?

Sign up to our newsletter