Christmas came early this year . After several years of delay, the U.S. Food and Drug Administration (FDA) issued its computer software assurance (CSA) guidance. It’s been on the agency’s priority list for a while, but a slew of other concerns kept bumping this back. Squeezing it in at the end of fiscal year 2022, the software validation guidance was released mid-September and is open for comments until November 14.
Computer software validation has traditionally been a burden, so “Computer Software Assurance for Production and Quality Systems Software” comes as a relief. Now that it’s out, here are some things from the guidance to keep in mind the next time a validation project comes up.
We’ve written about taking a risk-based approach to validation before. Deciding how to validate based on risk is the key to reducing validation burden, ensuring “the burden of validation is no more than necessary to address the risk.”
Keep in mind, the FDA is primarily concerned about a software feature, function, or operation failing and resulting in a quality problem that might compromise safety. If a failure would affect quality, but not pose a safety issue, the FDA doesn’t consider it high risk. Life sciences companies have other concerns, but for regulatory compliance purposes, this is primarily what needs to be top of mind when performing computer software validation.
For years, we’ve been promoting the use of vendor documentation and testing as a way to reduce computer software validation burden. The FDA agrees: “The manufacturer could incorporate the practices, validation work, and electronic information already performed by developers of the software as the starting point and determine what additional activities may be needed. For some lower-risk software features, functions, and operations, this may be all the assurance that is needed.”
There’s a big difference between what the FDA categorizes as unscripted and scripted testing. Unscripted testing includes ad-hoc testing, error-guessing, and exploratory testing. These are less formal and don’t rely on written instructions in a test case. Depending on the level of risk, these might be sufficient quality assurance activities.
Scripted testing includes the more work-intensive robust and limited scripted testing . High-risk software features will probably require these more rigorous approaches normally associated with computer software validation.
Computer software assurance, according to this guidance, should produce less paperwork than expected. The FDA outlines exactly what needs to be recorded:
To show what this would look like in practice, the software validation guidance gives an example. It’s less than a page long, strongly implying that stacks of documents are unnecessary to prove compliance.
The FDA would really like it if you digitized . They didn’t exactly say that in the guidance document. But what they did say was, “As a least burdensome method, FDA recommends the use of electronic records, such as system logs, audit trails, and other data generated by the software, as opposed to paper documentation and screenshots.”
Granted, this is a recommendation, not a requirement. However, using electronic records doesn’t just simplify the computer software assurance process — it simplifies every compliance activity. Document control, training, quality event management, etc. can all be interconnected and automated when an electronic quality management system is used.
The software validation guidance isn’t terribly long — it’s 25 pages including appendices. However, we still couldn’t cover it all in a single blog post. You can read the entire guidance for yourself here. The document has very specific examples that will help quality personnel better understand what the agency expects.
Still have validation questions? Our validation expert Vice President of Product Management Erin Wright answers some common validation questions here.
Enjoying this blog? Learn More.
8 Tips for Compliant and Quick Software ValidationGet the Guide