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?
Which software falls within the scope of the regulations?
How do you validate?
- 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.
So which approach can be used for this?
- List all software packages used in relationship to your QMS processes
- Do a risk analysis of your use of the software
- To support your own validation activities, obtain as much as possible release notes, validation and verification documentation from the suppliers of the software
- List the requirements that YOU have for these software packages
- Define tests that focus on these requirements (and taking the defined risks into account)
- Execute the tests
- Make sure you document the results and have a conclusion
- Define when re-validation of the software is required (upgrade, change of operating system, ....)
- 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!