We’ll cut to the chase: you have to qualify and validate your eQMS software. There’s no way around it, especially if you care about patient data safety (and of course, FDA regulations). Unfortunately, the thought of validating software makes most quality teams cringe. Even the FDA has acknowledged that the industry has over complicated Computer Systems Validation (CSV).
But, a proper qualification and validation will give you peace of mind about your data and electronic signatures' integrity. And that's really the point, isn't it? Plus, the long-term consequences of a failed or inadequate validation is not fun.
Thankfully, the FDA has released some new validation guidelines that lighten the load without losing the impact. Let’s cover the basics.
What is software validation?
Validation is the process of confirming that a piece of software does what it says it can do, meets your requirements as a user, and protects both your organization’s and your consumers’ data. In the life sciences industry, companies are required by the FDA to carry out validation on all software that could impact quality, safety, or effectiveness. That includes your eQMS.
When the FDA auditor arrives, you’ll need to prove the eQMS you chose is fit for your needs and that you followed your SOPs to qualify it.
“Prove” is the key word here. It means you must have:
- A documented set of requirements for your needs
- Documentation of how your selected eQMS meets those core requirements and how you confirmed it
These documents will help you when the auditor asks questions like:
- Did you follow your own SOPs?
- Where’s the audit and risk assessment?
- Is your qualification based on your risk assessment?
- Can you explain/ defend it easily?
Old vs New: Software validation guidelines
You’ll notice a few of the auditor questions above focus on a “risk assessment.” That’s a result of new software validation guidelines from the FDA.
The old CSV approach was all about checking the validation boxes without considering different levels of risk associated with the software you’re qualifying. That created a lot more work and documentation than necessary.
But the FDA’s recent move to Computer Software Assurance (CSA) and the new GAMP5 guidelines call for a mindset switch. This approach is risk-based and focuses on the software’s intended use, its level of customization, the phase of your product, and each feature’s level of impact on your operation and safety as a whole.
Depending on where the software falls on the risk-based scale, the complexity of validation goes up or down.
For example, an eQMS built in-house at your organization or a heavily-customized system will naturally lead to a more stringent validation process. Whereas an eQMS that was developed in accordance with all relevant standards, has a defined quality manual, and has its own validation documentation will be a much lighter lift for your organization. In fact, the new guidance encourages leveraging the validation efforts of your service providers – something many were hesitant to do under the old guidelines.
With this new school of thought, patient safety and product quality are still prioritized while workload and documentation are drastically reduced.
Key Takeaway: The FDA says format and structure aren’t as important as information. Instead of restrictive templates, focus on proving the best fit-for-purpose, contextualize the risk, and recognize that not all feature failures are fatal.
How to validate a cloud-based eQMS
SaaS platforms should already have core validation documents in place and ready for review. That means you’ll just need a memo or qualification document that:
- Describes the need for an eQMS, including a basic list of your requirements
- Describes your vendor selection decision, including mitigation for any critical missing requirements
- References your audit/risk assessment of the selected vendor and vendor documentation
- Justifies your qualification on a risk-based approach. (This should link back to your audit/risk assessment above and document your expected approach to acceptance testing and any re-qualifications for updates.)
- Documents your User Acceptance Testing (or Mini-PQ) that proves your specific configuration of the software is "fit for your purpose.” (In this case, you aren't verifying the system functionality – the vendor did that! – you’re verifying the categories, workflows, user groups etc. are all set based on your specifications.)
Our validation soapbox
Unfortunately, a lot of eQMS vendors charge clients extra fees to access their validation documents. We think that’s uncool. It forces clients to either start validation from scratch (a time-intensive process with a lot of room for error) or to fork up more money on top of the core software cost. Plus, every time a client has to revalidate the system (like after a software update), they’re hit with the validation fee all over again.
Software validation is a non-negotiable—it has a big impact on consumer safety and on the stress levels of your quality team. That’s why we don't charge for validation documents, re-qualification, or for our support in the process – it’s all included within our one-time, fixed implementation fee. And that should be standard.