I’ve consulted with life sciences companies on system selection, system implementation, and computer validation for nearly 14 years (and have been doing this work for over 20) and the work that I used to do (and couldn’t keep up with) has slowly disappeared and it just doesn’t make sense.
I know that biotech companies aren’t building internal computer validation and system talent as most emerging biotech companies are outsourcing their IT to companies so that they can focus on the science, including clinical and regulatory, to get a product to market. SaaS and cloud solutions have made it incredibly easy for biotech companies (and others in life sciences) to shove off IT and system responsibilities to external vendors.
Quality Assurance (QA) departments have been reluctant to take on responsibility for computer validation because it is just so different from process validation, equipment validation, batch release, and documentation management functions. This has included a reluctance to see IT vendors, including SaaS, external hosting providers, and cloud vendors, as ‘suppliers’ to be audited and maintained on an Approved Supplier List.
So what are life sciences companies doing to ensure compliance with regulations such as 21 CFR Part 11 for electronic records and electronic signatures?
Based on my research, life sciences companies are happily shifting the responsibility and throwing it ‘over the fence’ to the vendors. The vendors are including language in their sales material and pitches claiming to have ‘validated’ solutions so it seems that the situation is a win-win.
But is it?
Validating for Intended Use
The simple answer is, no.
21 CFR Part 11.10 specifically calls out for ‘validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid and altered records.’ Consistent intended performance is key here and what I, and other experts in the field, interpret as ‘validating for intended use.’
No vendor can fully anticipate a customer’s intended use and therefore can’t provide a validated system without defining the intended use and verifying the system meets those requirements. Every company has different processes and procedures and configures systems for their intended use thereby making it impossible for a vendor to claim they have a ‘validated system’ during the sales cycle.
We Relied on the Vendor’s Claim, Now What Do We Do?
Great question and I am so happy you asked it. You are taking a step in the right direction.
There are few things you can do based on the level of risk associated with the system and the data contained therein.
- Assess the risk level for the system with justification for the risk assessment. This will drive all subsequent activities.
- Based on the risk assessment, review the validation activities performed against what would have been done if the validation was performed proactively. Document the review.
- Identify any gaps, assess the risks, and begin to address and mitigate the issues. I recommend generating a CAPA for the work depending on how the company’s deviation/CAPA program works. For most companies, IT systems (internal or external) are inappropriately excluded from the scope of Quality oversight. Therefore the lack of validation doesn’t end up being a deviation from internal policies or procedures. If you have questions on how to validate a SaaS solution, you can read more about it in a related SaaS system blog post.
- For medium to high risk systems, I recommend performing a vendor audit to understand what the vendor is doing and ensure that their practices meet your company’s minimum requirements. They shouldn’t be treated any differently than a contract manufacturer (CMO). Any observations should be documented in the audit report and followed up on per the company’s external audit procedures. Once again, most Quality groups struggle to include IT system vendors in their audit program but should be including them.
- Leverage what you can from your vendors but in some cases, additional validation deliverables will need to be developed. These may include requirements specifications, procedures, validation protocols (PQ), training, data verification documentation, among others. If the system is determined to not have been ‘in control’ for a period of time, the integrity of the data could be in question and additional verification activities may be required.
- Finally, generate a validation summary report and include a description of the system, the risk assessment and justification, and the validation activities performed to comply with the requirement to ‘validate for intended use.’
- Don’t forget to include the procedures to ensure that the system remains validated including controlling access to the system and change control procedures. I always recommend a change assessment template for my clients to use when their vendors release new versions and update the SaaS solutions.
Still Have Questions or Wondering if Your System is in Compliance?
Feel free to reach out to me with any questions you might have via email at email@example.com or through my website SolutionsProjects, LLC. I provide an initial assessment by phone for new clients, free of charge, to help make sure you are in compliance or get you on the path to compliance.
Keep in mind that it is generally not in your vendor’s best interest to fully inform you of the true level of effort to validate a SaaS solution in the life sciences space. The vendors are incentivized to minimize the effort to get you to sign on the dotted line. It’s not really their problem but yours: they are not going to be the ones demonstrating data integrity and data reliability for electronic records and signatures subject to 21 CFR Part 11 or used in a regulatory submission; you are.
Related article: Ticking Time Bomb: SaaS in Life Sciences