How to validate QMS software efficiently?

Not only software used for production but also software used in your Quality management System (QMS) needs to be validated.

Legislation and various standards dictate the requirement to validate the software used in your QMS.

21 CFR 820.70 (i) reads:

Automated processes. When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.

ISO 13485:2016 reads:

4.1.6 The organization shall document procedures for the validation of the application of computer
software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application.
The specific approach and activities associated with software validation and revalidation shall be
proportionate to the risk associated with the use of the software.
Records of such activities shall be maintained (see 4.2.5).

So what is expected?

All software that is used (entirely or partially) in relation to the quality system should be validated. Moreover, you need procedures that document how you will validate and re-validate these tools. 

ISO/TR 80002-2:2017 gives guidance of what is expected with regards to software validation (both for software used in the QMS as well as software used in production and servicing).

In short, what is expected is that you perform a set of activities that provide a level of confidence in the ability of the software to perform according to its intended use.

Which activities these are, depends on the complexity of the software, the risk of harm and how much information is provided by the software supplier.

Which software falls within the scope of the regulations?

These requirements are not only applicable for eQMS software that manage your entire QMS. This is also applicable to software that is used for ERP (Enterprise Resource Planning) purposes or the formulas in Excel sheets that you might use for CAPAs or complaints.

The regulations do not apply, for example, to software used for invoicing or mailing systems.

How do you validate?

It all starts with the question what the software is used for. What is its intended use within your processes? What are the companies requirements for such software?

It's highly unlikely that you are using the full functionality of any software linked to your quality system,  and therefore you don't have to validate each and every feature.

What is important is that you validate the way you use it.

• If you use certain formulas or macros in Excel, you need to validate the output of those formulas and macros.

• If you use an Enterprise Resource Planning (ERP) system to document the traceability of your devices in the market, you should validate that the output is indeed correct.

• When you use an eQMS software to create procedures and records, you should indeed validate that this is working correctly.

And don't forget to validate electronic signatures/records according to 21CFR Part 11 if that is applicable to you.

Next to the definition of the intended use and your requirements for the software, another parameter is the amount of information you receive from the software supplier.

When you create the software yourself, it's obvious you'll have to provide all documentation yourself, but when you purchase (part of) a software, you can obtain documentation from your supplier to build the basis of your validation.

ISO/TR 80002-2 offers you a toolbox of possible activities which you can implement in order to build the level of confidence in the software that is needed based on your risk assessment.

Not only the initial deployment of the software requires validation. Again, depending on the intended use and the risk assessment, there should be a re-validation plan for whenever the software changes.

So which approach can be used for this?

1. List all software packages used in relationship to your QMS processes

2. Do a risk analysis of your use of the software

3. To support your own validation activities, obtain as much as possible release notes, validation and verification documentation from the suppliers of the software

4. List the requirements that YOU have for these software packages

5. Define tests that focus on these requirements (and taking the defined risks into account)

6. Execute the tests

7. Make sure you document the results and have a conclusion

8. Define when re-validation of the software is required (upgrade, change of operating system, ....)

9. Create a procedure that describes the above

Depending on the application of the software, the risk involved and the organizational structure, you might consider validating the software first in a test environment and afterwards in the real environment.

For more complex validation processes, it's a good idea to create a validation plan that guides you on what needs to be tested, when, how and by whom. Here you can take into account the actual part of the software functionality that changed.

In general, it is recommended to keep the same structure for your validation documentation throughout the whole set of tools that you need to validate. 

We support our customers by providing a full set of validation documentation for our products.

For more information, contact us!