Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


Validation of software used in production and QMS - Part 3 Validation Protocol and Reports

We continue this series on validation of software used in production and QMS with the Validation Protocol and Reports.

The Validation Master Plan (VMP) comes with other documents:

I share these templates with the conditions of CC-BY-NC-ND license.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.

Content of the Validation Protocol

The validation protocol is the instanciation of the provisions of the Validation Master Plan (VMP). You will have one validation protocol per system needing validation.
The content of the validation protocol repeats the phases found in the VMP, with specific provisions, if needed.

For example, a system of low level of concern may have a validation protocol with IQ and PQ only, considering that OQ is not mandatory given the system features. Of course, skipping OQ shall be documented!

Content of the Validation Reports

The validation reports are simply the records of validation protocol.

Validation Report

The validation report is filled with data gathered during qualification phases. There may be a single report recording all phases or multiple reports. When qualification phases are long or verbose, having a report per phase is a good option.
The validation report ends with a conclusion about the conformity of the product versus requirements verified during the phase. It's important to keep this part hence it inks the status of the system at the end of the phase. That's also a cultural way of doing this in the world of physical equipment qualification!

Final Validation Report

The final validation report contains:

  • The identification of the system that is validated,
  • The final conclusion about the validation.

The identification is important, to be sure which version is validated and who can use what in routine. This is also a favorite way of auditors to search for pitfalls in the identification of the validated system.
The final conclusion is about the compliance of the system versus regulatory requirements. Note the difference between validation reports (compliance to requirements in the scope of the phase) and the final validation report (compliance to regulatory requirements).


That's the end of this series about computerized systems validations.
With all this templates and explanations, you should be ready to perform you own computerized systems validations. Feel free to ask questions in comments!



Comments

1. On Thursday 3 September 2015, 17:13 by Chouquette

Thanks Mitch for these detailled explanations.
Your articles are very interesting and summarize the validation process :)

2. On Friday 4 September 2015, 07:16 by Mitch

Thanks for your feedback, Chouquette! :-D

3. On Thursday 22 December 2016, 10:02 by BP

Mitch,
Thanks a lot for this very interesting series, and for the useful templates.

You are not mentioning the necessary updates of software, especially the minor ones (example: from Atlassian Confluence 7.1 to 7.2). Would you go for a lighter process here?

4. On Monday 2 January 2017, 22:18 by Mitch

Hi BP,

Yes, definitely.

You can use a risk-based approach on the content of the update to do a light revalidation.

Cheers

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed